The edge layer of \gls{IOT} systems predominantly consists of microcontrollers.
Microcontrollers are tiny computers designed specifically for embedded applications.
-They differ significantly from regular computers in many aspects, and as a consequence, development for microcontrollers differs also.
+They differ significantly from regular computers in many aspects.
For example, they are much smaller; only have a fraction of the memory and processor speed; and run on different architectures.
Furthermore, they have much more energy-efficient sleep modes, and support connecting and interfacing with peripherals such as sensors and actuators.
To illustrate the difference in characteristics, \cref{tbl:mcu_laptop} compares the hardware properties of a typical laptop with two popular microcontrollers.
+As a consequence of these differences, development for microcontrollers is also unlike development for traditional computers.
Usually, programming microcontrollers requires an elaborate multistep toolchain of compilation, linkage, binary image creation, and burning this image onto the flash memory of the microcontroller in order to run a program.
The software is usually a cyclic executive instead of tasks that run in an \gls{OS}.
Hence, all tasks must be manually combined into a single program.
Such web applications often form the core of the topmost two layers of \gls{IOT} applications: the presentation and application layer.
Furthermore, \gls{IOT} edge devices are typically programmed with similar workflow-like programs for which \gls{TOP} is very suitable.
Directly incorporating the perception layer, and thus edge devices, in \gls{ITASK} however is not straightforward.
-The \gls{ITASK} system is targetting relatively fast and hence energy-hungry systems with large amounts of \gls{RAM} and a speedy connection.
+All \gls{ITASK} applications carry the weigth of multi-user \gls{TOP} programs that can generically generate webpages, communication, and storage for all data types in the program.
+As a result, the \gls{ITASK} system targetting relatively fast and hence energy-hungry systems with large amounts of \gls{RAM} and a speedy connection.
Edge devices in \gls{IOT} systems are typically slow but energy efficient and do not have the memory to run the naturally heap-heavy feature-packed functional programs that \gls{ITASK} programs are.
The \gls{MTASK} system bridges this gap by providing a domain-specific \gls{TOP} language for \gls{IOT} edge devices.
Domain-specific knowledge is embedded in the language and execution platform and unnecessary features for edge devices are removed to drastically lower the hardware requirements.
The task resulting from the main expression is continuously executed by the \gls{RTS}.
To simulate a loop, the \cleaninline{rpeat} task combinator is used as this task combinator executes the argument task and, when stable, reinstates it.
The body of the \cleaninline{rpeat} task contains a task that writes to the pins and waits in between.
-The tasks are connected using the sequential \cleaninline{>>|.} combinator that for all current intents and purposes executes the tasks after each other.
+The tasks are connected using the sequential \cleaninline{>>\|.} combinator that for all current intents and purposes executes the tasks after each other.
\begin{lstClean}[caption={Blinking the \gls{LED} using the \cleaninline{rpeat} combinator.},label={lst:blinkImp}]
blinkTask :: Main (MTask v ()) | mtask v
The \gls{MTASK} \gls{DSL} is hosted in a full-fledged \gls{FP} language.
It is therefore also possible to define the blinking behaviour as a function.
\Cref{lst:blinkFun} shows this more natural translation.
-The \cleaninline{main} expression is a call to the \cleaninline{blink} function parametrised with the state.
+The \cleaninline{main} expression is a call to the \cleaninline{blink} \gls{MTASK} function parametrised with the state.
The \cleaninline{blink} function first writes the current state to the \gls{LED}, waits for the specific time, and calls itself recursively with the inverse of the state, resulting in the blinking behaviour.
Creating recursive functions like this is not possible in the \gls{ARDUINO} language because the program would run out of stack quickly and combining multiple tasks defined like this would be very difficult.
Consequently, and in contrast to \gls{ARDUINO}, the \cleaninline{delay} task in \gls{MTASK} does not block the execution.
It has no observable value until the target waiting time has passed, and is thence \emph{stable}.
As there is no global state, the function is parametrised with the current status, the pin to blink and the waiting time.
-With a parallel combinator, tasks are executed at the same time.
+With a parallel combinator, tasks are executed seamingly at the same time, i.e.\ their very short small-step reduction steps are interleaved.
Therefore, blinking three different blinking patterns is as simple as combining the three calls to the \cleaninline{blink} function with their arguments as seen in \cref{lst:blinkthreadmtask}.
% VimTeX: SynIgnore on
\begin{lstClean}[label={lst:blinkthreadmtask},caption={Threading three blinking patterns.}]
blinktask :: MTask v () | mtask v
-blinktask = declarePin D1 PMOutput \d1->
+blinktask =
+ declarePin D1 PMOutput \d1->
declarePin D2 PMOutput \d2->
declarePin D3 PMOutput \d3->
fun \blink=(\(st, pin, wait)->
delay wait
- >>|. writeD d13 st
+ >>|. writeD pin st
>>|. blink (Not st, pin, wait))
In {main = blink (true, d1, lit 500)
.||. blink (true, d2, lit 300)
% VimTeX: SynIgnore off
\section{Conclusion and reading guide}
+\todo[inline]{Reading guide noemen ipv conclusion omdat:
+Veel van wat hier staat is geen conclusie van het voorgaande. Kun je dit niet beter reading guide noemen?}
This chapter introduced traditional edge device programming and programming edge devices using \gls{MTASK}.
+\todo[inline]{Anders dan de titel van dit hoofdstuk suggereert, geeft dit maar een heel beperkt overzicht van TOP in mTask.
+
+ Zou je niet expliciet noemen dat je task resulten kunt gebruiken, conditionals en een step combinator hebt etc. Voorbeelden van alles lijkt me niet nodig.
+
+Ook zou ik de SDS en integratie met iTask nog eens noemen te verwijzen naar de introductie.
+Iets over semantiek zeggen?}
The edge layer of \gls{IOT} systems is powered by microcontrollers.
Microcontrollers have significantly different characteristics to regular computers.
Programming them happens through compiled firmwares using low-level imperative programming languages.
}
The following chapters of this monograph thoroughly introduce all aspects of the \gls{MTASK} system.
-First the language setup and interface are shown in \cref{chp:mtask_dsl}.
+First, the language setup and interface are shown in \cref{chp:mtask_dsl}.
\Cref{chp:integration_with_itask} shows the integration of \gls{MTASK} and \gls{ITASK}.
Then, \cref{chp:implementation} provides the implementation of the \gls{DSL}, the compilation schemes, instruction set, and details on the interpreter.
\Cref{chp:green_computing_mtask} explains all green computing aspects of \gls{MTASK}, i.e.\ task scheduling and processor interrupts.
repositories / phd-thesis.git / blobdiff