top/top.tex

   1 \documentclass[../thesis.tex]{subfiles}
   2
   3 \input{subfilepreamble}
   4
   5 \begin{document}
   6 \ifSubfilesClassLoaded{
   7         \pagenumbering{arabic}
   8 }{}
   9
  10 \chapter{Edge device programming}%
  11 \label{chp:top4iot}
  12 \todo{betere chapter naam}
  13 \begin{chapterabstract}
  14         This chapter introduces \gls{MTASK} and puts it into perspective compared to traditional microcontroller programming.
  15         It does so by showing how to program microcontrollers using \gls{ARDUINO}, a popular microcontroller framework, and the equivalent \gls{MTASK} programs.
  16 \end{chapterabstract}
  17
  18 The edge layer of \gls{IOT} system mostly consists of microcontrollers that require a different method of programming.
  19 Usually, programming microcontrollers requires an elaborate multi-step toolchain of compilation, linkage, binary image creation, and burning this image onto the flash memory of the microcontroller in order to compile and run a program.
  20 The programs are usually cyclic executives instead of tasks running in an operating system, i.e.\ there is only a single task that continuously runs on the bare metal.
  21 Each type of microcontrollers comes with vendor-provided drivers, compilers and \glspl{RTS} but there are many platform that abstract away from this such as \gls{MBED} and \gls{ARDUINO} of which \gls{ARDUINO} is specifically designed for education and prototyping and hence used here.
  22 The popular \gls{ARDUINO} \gls{C}\slash\gls{CPP} dialect and accompanying libraries provide an abstraction layer for common microcontroller behaviour allowing the programmer to program multiple types of microcontrollers using a single language.
  23 Originally it was designed for the in-house developed open-source hardware with the same name but the setup allows porting to many architectures.
  24 It provides an \gls{IDE} and toolchain automation to perform all steps of the toolchain with a single command.
  25
  26 \section{Hello world!}
  27 Traditionally, the first program that one writes when trying a new language is the so called \emph{Hello World!} program.
  28 This program has the single task of printing the text \emph{Hello World!} to the screen and exiting again, useful to become familiarised with the syntax and verify that the toolchain and runtime environment is working.
  29 On microcontrollers, there usually is no screen for displaying text.
  30 Nevertheless, almost always there is a built-in monochrome $1\times1$ pixel screen, namely an \gls{LED}.
  31 The \emph{Hello World!} equivalent on microcontrollers blinks this \gls{LED}.
  32
  33 \Cref{lst:arduinoBlink} shows how the logic of a blink program might look when using \gls{ARDUINO}'s \gls{C}\slash\gls{CPP} dialect.
  34 Every \gls{ARDUINO} program contains a \arduinoinline{setup} and a \arduinoinline{loop} function.
  35 The \arduinoinline{setup} function is executed only once on boot, the \arduinoinline{loop} function is continuously called afterwards and contains the event loop.
  36 After setting the \gls{GPIO} pin to the correct mode, blink's \arduinoinline{loop} function alternates the state of the pin representing the \gls{LED} between \arduinoinline{HIGH} and \arduinoinline{LOW}, turning the \gls{LED} off and on respectively.
  37 In between it waits for \qty{500}{\ms} so that the blinking is actually visible for the human eye.
  38
  39 Translating the traditional blink program to \gls{MTASK} can almost be done by simply substituting some syntax as seen in \cref{lst:blinkImp}.
  40 E.g.\ \arduinoinline{digitalWrite} becomes \cleaninline{writeD}, literals are prefixed with \cleaninline{lit} and the pin to blink is changed to represent the actual pin for the builtin \gls{LED} of the device used in the exercises.
  41 In contrast to the imperative \gls{CPP} dialect, \gls{MTASK} is a \gls{TOP} language and therefore there is no such thing as a loop, only task combinators to combine tasks.
  42 To simulate a loop, the \cleaninline{rpeat} task combinator can be used as this task combinator executes the argument task and, when stable, reinstates it.
  43 The body of the \cleaninline{rpeat} contains similarly named tasks to write to the pins and to wait in between.
  44 The tasks are connected using the sequential \cleaninline{>>|.} combinator that for all current intents and purposes executes the tasks after each other.
  45
  46 \begin{figure}[ht]
  47         \begin{subfigure}[b]{.5\linewidth}
  48                 \begin{lstArduino}[caption={Blink program.},label={lst:arduinoBlink}]
  49 void setup() {
  50         pinMode(D2, OUTPUT);
  51 }
  52
  53 void loop() {
  54         digitalWrite(D2, HIGH);
  55         delay(500);
  56         digitalWrite(D2, LOW);
  57         delay(500);
  58 }
  59                 \end{lstArduino}
  60         \end{subfigure}%
  61         \begin{subfigure}[b]{.5\linewidth}
  62                 \begin{lstClean}[caption={Blink program.},label={lst:blinkImp}]
  63 blink :: Main (MTask v ()) | mtask v
  64 blink =
  65         declarePin D2 PMOutput \d2->
  66         {main = rpeat (
  67                      writeD d2 true
  68                 >>|. delay (lit 500)
  69                 >>|. writeD d2 false
  70                 >>|. delay (lit 500)
  71         )
  72 }
  73                 \end{lstClean}
  74         \end{subfigure}
  75 \end{figure}
  76
  77 \section{Threaded blinking}
  78 Now say that we want to blink multiple blinking patterns on different \glspl{LED} concurrently.
  79 For example, blink three \glspl{LED} connected to \gls{GPIO} pins $1,2$ and $3$ at intervals of \qtylist{500;300;800}{\ms}.
  80 Intuitively you want to lift the blinking behaviour to a function and call this function three times with different parameters as done in \cref{lst:blinkthreadno}
  81
  82 \begin{lstArduino}[caption={Naive approach to multiple blinking patterns.},label={lst:blinkthreadno}]
  83 void setup () { ... }
  84
  85 void blink (int pin, int wait) {
  86         digitalWrite(pin, HIGH);
  87         delay(wait);
  88         digitalWrite(pin, LOW);
  89         delay(wait);
  90 }
  91
  92 void loop() {
  93         blink (D1, 500);
  94         blink (D2, 300);
  95         blink (D3, 800);
  96 }\end{lstArduino}
  97
  98 Unfortunately, this does not work because the \arduinoinline{delay} function blocks all further execution.
  99 The resulting program will blink the \glspl{LED} after each other instead of at the same time.
 100 To overcome this, it is necessary to slice up the blinking behaviour in very small fragments so it can be manually interleaved \citep{feijs_multi-tasking_2013}.
 101 Listing~\ref{lst:blinkthread} shows how three different blinking patterns might be achieved in \gls{ARDUINO} using the slicing method.
 102 If we want the blink function to be a separate parametrizable function we need to explicitly provide all references to the required state.
 103 Furthermore, the \arduinoinline{delay} function can not be used and polling \arduinoinline{millis} is required.
 104 The \arduinoinline{millis} function returns the number of milliseconds that have passed since the boot of the microcontroller.
 105 Some devices use very little energy when in \arduinoinline{delay} or sleep state.
 106 Resulting in \arduinoinline{millis} potentially affects power consumption since the processor is basically busy looping all the time.
 107 In the simple case of blinking three \glspl{LED} on fixed intervals, it might be possible to calculate the delays in advance using static analysis and generate the appropriate \arduinoinline{delay} code.
 108 Unfortunately, this is very hard when for example the blinking patterns are determined at runtime.
 109
 110 \begin{lstArduino}[label={lst:blinkthread},caption={Threading three blinking patterns.}]
 111 long led1 = 0, led2 = 0, led3 = 0;
 112 bool st1 = false, st2 = false, st3 = false;
 113
 114 void blink(int pin, int dlay, long *lastrun, bool *st) {
 115         if (millis() - *lastrun > dlay) {
 116                 digitalWrite(pin, *st = !*st);
 117                 *lastrun += dlay;
 118         }
 119 }
 120
 121 void loop() {
 122         blink(D1, 500, &led1, &st1);
 123         blink(D2, 300, &led2, &st1);
 124         blink(D3, 800, &led3, &st1);
 125 }\end{lstArduino}
 126
 127 This method is very error prone, requires a lot of pointer juggling and generally results into spaghetti code.
 128 Furthermore, it is very difficult to represent dependencies between threads, often state machines have to be explicitly programmed by hand to achieve this.
 129
 130 \section{Blinking in \texorpdfstring{\gls{MTASK}}{mTask}}
 131 The \cleaninline{delay} \emph{task} does not block the execution but \emph{just} emits no value when the target waiting time has not yet passed and emits a stable value when the time is met.
 132 In contrast, the \arduinoinline{delay()} \emph{function} on the \gls{ARDUINO} is blocking which prohibits interleaving.
 133 To make code reuse possible and make the implementation more intuitive, the blinking behaviour is lifted to a recursive function instead of using the imperative \cleaninline{rpeat} construct.
 134 The function is parametrized with the current state, the pin to blink and the waiting time.
 135 Creating recursive functions like this is not possible in the \gls{ARDUINO} language because the program would run out of stack in an instant and nothing can be interleaved.
 136 With a parallel combinator, tasks can be executed in an interleaved fashion.
 137 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}.
 138
 139 % VimTeX: SynIgnore on
 140 \begin{lstClean}[label={lst:blinkthreadmtask},caption={Threaded blinking.}]
 141 blinktask :: MTask v () | mtask v
 142 blinktask =
 143         declarePin D1 PMOutput \d1->
 144         declarePin D2 PMOutput \d2->
 145         declarePin D3 PMOutput \d3->
 146         fun \blink=(\(st, pin, wait)->
 147                      delay wait
 148                 >>|. writeD d13 st
 149                 >>|. blink (Not st, pin, wait)) In
 150         {main =  blink (true, d1, lit 500)
 151                 .||. blink (true, d2, lit 300)
 152                 .||. blink (true, d3, lit 800)
 153         }\end{lstClean}
 154 % VimTeX: SynIgnore off
 155
 156 \section{\texorpdfstring{\Gls{MTASK}}{MTask} history}
 157 \subsection{Generating \texorpdfstring{\gls{C}/\gls{CPP}}{C/C++} code}
 158 A first throw at a class-based shallowly \gls{EDSL} for microcontrollers was made by \citet{plasmeijer_shallow_2016}.
 159 The language was called \gls{ARDSL} and offered a type safe interface to \gls{ARDUINO} \gls{CPP} dialect.
 160 A \gls{CPP} code generation backend was available together with an \gls{ITASK} simulation backend.
 161 There was no support for tasks or even functions.
 162 Some time later in the 2015 \gls{CEFP} summer school, an extended version was created that allowed the creation of imperative tasks, \glspl{SDS} and the usage of functions \citep{koopman_type-safe_2019}.
 163 The name then changed from \gls{ARDSL} to \gls{MTASK}.
 164
 165 \subsection{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}
 166 \Citet{lubbers_task_2017} extended this in his Master's Thesis by adding integration with \gls{ITASK} and a bytecode compiler to the language.
 167 \Gls{SDS} in \gls{MTASK} could be accessed on the \gls{ITASK} server.
 168 In this way, entire \gls{IOT} systems could be programmed from a single source.
 169 However, this version used a simplified version of \gls{MTASK} without functions.
 170 This was later improved upon by creating a simplified interface where \glspl{SDS} from \gls{ITASK} could be used in \gls{MTASK} and the other way around \citep{lubbers_task_2018}.
 171 It was shown by \citet{amazonas_cabral_de_andrade_developing_2018} that it was possible to build real-life \gls{IOT} systems with this integration.
 172 Moreover, a course on the \gls{MTASK} simulator was provided at the 2018 \gls{CEFP}/\gls{3COWS} winter school in Ko\v{s}ice, Slovakia \citep{koopman_simulation_2018}.
 173
 174 \section{Transition to \texorpdfstring{\gls{TOP}}{TOP}}
 175 The \gls{MTASK} language as it is now was introduced in 2018 \citep{koopman_task-based_2018}.
 176 This paper updated the language to support functions, tasks and \glspl{SDS} but still compiled to \gls{CPP} \gls{ARDUINO} code.
 177 Later the bytecode compiler and \gls{ITASK} integration was added to the language \citep{lubbers_interpreting_2019}.
 178 Moreover, it was shown that it is very intuitive to write microcontroller applications in a \gls{TOP} language \citep{lubbers_multitasking_2019}.
 179 One reason for this is that a lot of design patterns that are difficult using standard means are for free in \gls{TOP} (e.g.\ multithreading).
 180 In 2019, the \gls{CEFP} summer school in Budapest, Hungary hosted a course on developing \gls{IOT} applications with \gls{MTASK} as well \citep{lubbers_writing_2019}.
 181
 182 \subsection{\texorpdfstring{\Glsxtrshort{TOP}}{TOP}}
 183 In 2022, the SusTrainable summer school in Rijeka, Croatia hosted a course on developing greener \gls{IOT} applications using \gls{MTASK} as well (the lecture notes are to be written).
 184 Several students worked on extending \gls{MTASK} with many useful features:
 185 \Citet{veen_van_der_mutable_2020} did preliminary work on a green computer analysis, built a simulator and explored the possibilities for adding bounded datatypes; \citet{boer_de_secure_2020} investigated the possibilities for secure communication channels; and \citet{crooijmans_reducing_2021} added abstractions for low-power operation to \gls{MTASK} such as hardware interrupts and power efficient scheduling (resulting in a paper as well \citet{crooijmans_reducing_2022}).
 186 \Citet{antonova_mtask_2022} defined a preliminary formal semantics for a subset of \gls{MTASK}.
 187 Moreover, plans for student projects and improvements include exploring integrating \gls{TINYML} into \gls{MTASK}; and adding intermittent computing support to \gls{MTASK}.
 188
 189 In 2023, the SusTrainable summer school in Coimbra, Portugal will host a course on \gls{MTASK} as well.
 190
 191 \subsection{\texorpdfstring{\gls{MTASK}}{mTask} in practise}
 192 Funded by the Radboud-Glasgow Collaboration Fund, collaborative work was executed with Phil Trinder, Jeremy Singer, and Adrian Ravi Kishore Ramsingh.
 193 An existing smart campus application was developed using \gls{MTASK} and quantitively and qualitatively compared to the original application that was developed using a traditional \gls{IOT} stack \citep{lubbers_tiered_2020}.
 194 This research was later extended to include a four-way comparison: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK} and \gls{MTASK} \citep{lubbers_could_2022}.
 195 Currently, power efficiency behaviour of traditional versus \gls{TOP} \gls{IOT} stacks is being compared as well adding a \gls{FREERTOS} implementation to the mix as well.
 196
 197 \chapter{The \texorpdfstring{\gls{MTASK}}{mTask} \texorpdfstring{\glsxtrshort{DSL}}{DSL}}%
 198 \label{chp:mtask_dsl}
 199 \begin{chapterabstract}
 200 This chapter serves as a complete guide to the \gls{MTASK} language, from an \gls{MTASK} programmer's perspective.
 201 \end{chapterabstract}
 202
 203 The \gls{MTASK} system is a complete \gls{TOP} programming environment for programming microcontrollers.
 204 It is implemented as an \gls{EDSL} in \gls{CLEAN} using class-based---or tagless-final---embedding (see \cref{sec:tagless-final_embedding}).
 205
 206 Due to the nature of the embedding technique, it is possible to have multiple views on-programs written in the \gls{MTASK} language.
 207 The following interpretations are available for \gls{MTASK}.
 208
 209 \begin{description}
 210         \item[Pretty printer]
 211
 212                 This interpretation converts the expression to a string representation.
 213         \item[Simulator]
 214
 215                 The simulator converts the expression to a ready-for-work \gls{ITASK} simulation in which the user can inspect and control the simulated peripherals and see the internal state of the tasks.
 216         \item[Byte code compiler]
 217
 218                 The compiler compiles the \gls{MTASK} program at runtime to a specialised byte code.
 219                 Using a handful of integration functions and tasks, \gls{MTASK} tasks can be executed on microcontrollers and integrated in \gls{ITASK} as if they were regular \gls{ITASK} tasks.
 220                 Furthermore, with special language constructs, \glspl{SDS} can be shared between \gls{MTASK} and \gls{ITASK} programs.
 221 \end{description}
 222
 223 When using the compiler interpretation in conjunction with the \gls{ITASK} integration, \gls{MTASK} is a heterogeneous \gls{DSL}.
 224 I.e.\ some components---e.g.\ the \gls{RTS} on the microcontroller---is largely unaware of the other components in the system, and it is executed on a completely different architecture.
 225 The \gls{MTASK} language is an enriched simply-typed $\lambda$-calculus with support for some basic types, arithmetic operations, and function definition; and a task language (see \cref{sec:top}).
 226
 227 \section{Types}
 228 To leverage the type checker of the host language, types in the \gls{MTASK} language are expressed as types in the host language, to make the language type safe.
 229 However, not all types in the host language are suitable for microcontrollers that may only have \qty{2}{\kibi\byte} of \gls{RAM} so class constraints are therefore added to the \gls{DSL} functions.
 230 The most used class constraint is the \cleaninline{type} class collection containing functions for serialization, printing, \gls{ITASK} constraints \etc.
 231 Many of these functions can be derived using generic programming.
 232 An even stronger restriction on types is defined for types that have a stack representation.
 233 This \cleaninline{basicType} class has instances for many \gls{CLEAN} basic types such as \cleaninline{Int}, \cleaninline{Real} and \cleaninline{Bool}.
 234 The class constraints for values in \gls{MTASK} are omnipresent in all functions and therefore often omitted throughout throughout the chapters for brevity and clarity.
 235
 236 \begin{table}[ht]
 237         \centering
 238         \begin{tabular}{lll}
 239                 \toprule
 240                 \gls{CLEAN}/\gls{MTASK} & \gls{CPP} type & \textnumero{}bits\\
 241                 \midrule
 242                 \cleaninline{Bool}             & \cinline{bool}    & 16\\
 243                 \cleaninline{Char}             & \cinline{char}    & 16\\
 244                 \cleaninline{Int}              & \cinline{int16_t} & 16\\
 245                 \cleaninline{:: Long}          & \cinline{int32_t} & 32\\
 246                 \cleaninline{Real}             & \cinline{float}   & 32\\
 247                 \cleaninline{:: T = A \| B \| C} & \cinline{enum}    & 16\\
 248                 \bottomrule
 249         \end{tabular}
 250         \caption{Mapping from \gls{CLEAN}/\gls{MTASK} data types to \gls{CPP} datatypes.}%
 251         \label{tbl:mtask-c-datatypes}
 252 \end{table}
 253
 254 \Cref{lst:constraints} contains the definitions for the auxiliary types and type constraints (such as \cleaninline{type} an \cleaninline{basicType}) that are used to construct \gls{MTASK} expressions.
 255 The \gls{MTASK} language interface consists of a core collection of type classes bundled in the type class \cleaninline{class mtask}.
 256 Every interpretation implements the type classes in the \cleaninline{mtask} class
 257 There are also \gls{MTASK} extensions that not every interpretation implements such as peripherals and \gls{ITASK} integration.
 258 \begin{lstClean}[caption={Classes and class collections for the \gls{MTASK} language.},label={lst:constraints}]
 259 class type t | iTask, ... ,fromByteCode, toByteCode t
 260 class basicType t | type t where ...
 261
 262 class mtask v | expr, ..., int, real, long v
 263
 264 \end{lstClean}
 265
 266 Sensors, \glspl{SDS}, functions, \etc{} may only be defined at the top level.
 267 The \cleaninline{Main} type is used that is used to distinguish the top level from the main expression.
 268 Some top level definitions, such as functions, are defined using \gls{HOAS}.
 269 To make their syntax friendlier, the \cleaninline{In} type---an infix tuple---is used to combine these top level definitions as can be seen in \cleaninline{someTask} (\cref{lst:mtask_types}).
 270
 271 \begin{lstClean}[caption={Example task and auxiliary types in the \gls{MTASK} language.},label={lst:mtask_types}]
 272 :: Main a = { main :: a }
 273 :: In a b = (In) infix 0 a b
 274
 275 someTask :: MTask v Int | mtask v & liftsds v & sensor1 v & ...
 276 someTask =
 277         sensor1 config1 \sns1->
 278         sensor2 config2 \sns2->
 279            sds \s1=initial
 280         In liftsds \s2=someiTaskSDS
 281         In fun \fun1= ( ... )
 282         In fun \fun2= ( ... )
 283         In { main = mainexpr }
 284 \end{lstClean}
 285
 286 \section{Expressions}\label{sec:expressions}
 287 \Cref{lst:expressions} shows the \cleaninline{expr} class containing the functionality to lift values from the host language to the \gls{MTASK} language (\cleaninline{lit}); perform number and boolean arithmetics; do comparisons; and conditional execution.
 288 For every common boolean and arithmetic operator in the host language, an \gls{MTASK} variant is present, suffixed by a period to not clash with \gls{CLEAN}'s builtin operators.
 289
 290 \begin{lstClean}[caption={The \gls{MTASK} class for expressions},label={lst:expressions}]
 291 class expr v where
 292         lit :: t -> v t | type t
 293         (+.) infixl 6 :: (v t) (v t) -> v t | basicType, +, zero t
 294         ...
 295         (&.) infixr 3 :: (v Bool) (v Bool) -> v Bool
 296         (|.) infixr 2 :: (v Bool) (v Bool) -> v Bool
 297         Not           :: (v Bool) -> v Bool
 298         (==.) infix 4 :: (v a) (v a) -> v Bool | Eq, basicType a
 299         ...
 300         If :: (v Bool) (v t) (v t) -> v t | type t
 301 \end{lstClean}
 302
 303 Conversion to-and-fro data types is available through the overloaded functions \cleaninline{int}, \cleaninline{long} and \cleaninline{real} that will convert the argument to the respective type similar to casting in \gls{C}.
 304
 305 \begin{lstClean}[caption={Type conversion functions in \gls{MTASK}.}]
 306 class int  v a :: (v a) -> v Int
 307 class real v a :: (v a) -> v Real
 308 class long v a :: (v a) -> v Long
 309 \end{lstClean}
 310
 311 Values from the host language must be explicitly lifted to the \gls{MTASK} language using the \cleaninline{lit} function.
 312 For convenience, there are many lower-cased macro definitions for often used constants such as \cleaninline{true :== lit True}, \cleaninline{false :== lit False}, \etc.
 313
 314 \Cref{lst:example_exprs} shows some examples of these expressions.
 315 Since they are only expressions, there is no need for a \cleaninline{Main}.
 316 \cleaninline{e0} defines the literal $42$, \cleaninline{e1} calculates the literal $42.0$ using real numbers.
 317 \cleaninline{e2} compares \cleaninline{e0} and \cleaninline{e1} as integers and if they are equal it returns the \cleaninline{e2}$/2$ and \cleaninline{e0} otherwise.
 318
 319 \begin{lstClean}[label={lst:example_exprs},caption={Example \gls{MTASK} expressions.}]
 320 e0 :: v Int | expr v
 321 e0 = lit 42
 322
 323 e1 :: v Real | expr v
 324 e1 = lit 38.0 + real (lit 4)
 325
 326 e2 :: v Int | expr v
 327 e2 = if' (e0 ==. int e1)
 328         (int e1 /. lit 2) e0
 329 \end{lstClean}
 330
 331 \Gls{MTASK} is shallowly embedded in \gls{CLEAN} and the terms are constructed at runtime.
 332 This means that \gls{MTASK} programs can also be tailor-made at runtime or constructed using \gls{CLEAN} functions maximising the linguistic reuse \citep{krishnamurthi_linguistic_2001}
 333 \cleaninline{approxEqual} in \cref{lst:example_macro} performs an approximate equality---albeit not taking into account all floating point pecularities---.
 334 When calling \cleaninline{approxEqual} in an \gls{MTASK} function, the resulting code is inlined.
 335
 336 \begin{lstClean}[label={lst:example_macro},caption={Example linguistic reuse in the \gls{MTASK} language.}]
 337 approxEqual :: (v Real) (v Real) (v Real) -> v Real | expr v
 338 approxEqual x y eps = if' (x ==. y) true
 339         ( if' (x >. y)
 340                 (y -. x < eps)
 341                 (x -. y < eps)
 342         )
 343 \end{lstClean}
 344
 345 \subsection{Data types}
 346 Most of \gls{CLEAN}'s basic types have been mapped on \gls{MTASK} types.
 347 However, it can be useful to have access to compound types as well.
 348 All types in \gls{MTASK} must have a fixed size representation on the stack so sum types are not (yet) supported.
 349 While it is possible to lift types using the \cleaninline{lit} function, you cannot do anything with the types besides passing them around but they are being produced by some parallel task combinators (see \cref{sssec:combinators_parallel}).
 350 To be able to use types as first class citizens, constructors and field selectors are required (see \cref{chp:first-class_datatypes}).
 351 \Cref{lst:tuple_exprs} shows the scaffolding for supporting tuples in \gls{MTASK}.
 352 Besides the constructors and field selectors, there is also a helper function available that transforms a function from a tuple of \gls{MTASK} expressions to an \gls{MTASK} expression of a tuple.
 353 Examples for using tuple can be found in \cref{sec:mtask_functions}.
 354
 355 \begin{lstClean}[label={lst:tuple_exprs},caption={Tuple constructor and field selectors in \gls{MTASK}.}]
 356 class tupl v where
 357         tupl :: (v a) (v b) -> v (a, b) | type a & type b
 358         first :: (v (a, b)) -> v a | type a & type b
 359         second :: (v (a, b)) -> v b | type a & type b
 360
 361         tupopen f :== \v->f (first v, second v)
 362 \end{lstClean}
 363
 364 \subsection{Functions}\label{sec:mtask_functions}
 365 Adding functions to the language is achieved by type class to the \gls{DSL}.
 366 By using \gls{HOAS}, both the function definition and the calls to the function can be controlled by the \gls{DSL} \citep{pfenning_higher-order_1988,chlipala_parametric_2008}.
 367 The \gls{MTASK} only allows first-order functions and does not allow partial function application.
 368 This is restricted by using a multi-parameter type class where the first parameter represents the arguments and the second parameter the view.
 369 By providing a single instance per function arity instead of providing one instance for all functions and using tuples for the arguments this constraint can be enforced.
 370 Also, \gls{MTASK} only supports top-level functions which is enforced by the \cleaninline{Main} box.
 371 The definition of the type class and the instances for an example interpretation (\cleaninline{:: Inter}) are as follows:
 372
 373 \begin{lstClean}[caption={Functions in \gls{MTASK}.}]
 374 class fun a v :: ((a -> v s) -> In (a -> v s) (Main (MTask v u)))
 375         -> Main (MTask v u)
 376
 377 instance fun () Inter where ...
 378 instance fun (Inter a) Inter | type a where ...
 379 instance fun (Inter a, Inter b) Inter | type a, type b where ...
 380 instance fun (Inter a, Inter b, Inter c) Inter | type a, ... where ...
 381 ...
 382 \end{lstClean}
 383
 384 Deriving how to define and use functions from the type is quite the challenge even though the resulting syntax is made easier using the infix type \cleaninline{In}.
 385 \Cref{lst:function_examples} show the factorial function, a tail-call optimised factorial function and a function with zero arguments to demonstrate the syntax.
 386 Splitting out the function definition for each single arity means that that for every function arity and combination of arguments, a separate class constraint must be created.
 387 Many of the often used functions are already bundled in the \cleaninline{mtask} class constraint collection.
 388 \cleaninline{factorialtail} shows a manually added class constraint.
 389 Definiting zero arity functions is shown in the \cleaninline{zeroarity} expression.
 390 Finally, \cleaninline{swapTuple} shows an example of a tuple being swapped.
 391
 392 % VimTeX: SynIgnore on
 393 \begin{lstClean}[label={lst:function_examples},caption={Function examples in \gls{MTASK}.}]
 394 factorial :: Main (v Int) | mtask v
 395 factorial =
 396         fun \fac=(\i->if' (i <. lit 1)
 397                 (lit 1)
 398                 (i *. fac (i -. lit 1)))
 399         In {main = fac (lit 5) }
 400
 401 factorialtail :: Main (v Int) | mtask v & fun (v Int, v Int) v
 402 factorialtail =
 403            fun \facacc=(\(acc, i)->if' (i <. lit 1)
 404                         acc
 405                         (fac (acc *. i, i -. lit 1)))
 406         In fun \fac=(\i->facacc (lit 1, i))
 407         In {main = fac (lit 5) }
 408
 409 zeroarity :: Main (v Int) | mtask v
 410 zeroarity =
 411            fun \fourtytwo=(\()->lit 42)
 412         In fun \add=(\(x, y)->x +. y)
 413         In {main = add (fourtytwo (), lit 9)}
 414
 415 swapTuple :: Main (v (Int, Bool)) | mtask v
 416 swapTuple =
 417            fun \swap=(tupopen \(x, y)->tupl y x)
 418         In {main = swap (tupl true (lit 42)) }
 419 \end{lstClean}
 420 % VimTeX: SynIgnore off
 421
 422 \section{Tasks and task combinators}\label{sec:top}
 423 \Gls{MTASK}'s task language can be divided into three categories, namely
 424 \begin{enumerate*}
 425         \item Basic tasks, in most \gls{TOP} systems, the basic tasks are called editors, modelling the interactivity with the user.
 426                 In \gls{MTASK}, there are no \emph{editors} in that sense but there is interaction with the outside world through microcontroller peripherals such as sensors and actuators.
 427         \item Task combinators provide a way of describing the workflow.
 428                 They combine one or more tasks into a compound task.
 429         \item \glspl{SDS} in \gls{MTASK} can be seen as references to data that can be shared using many-to-many communication and are only accessible from within the task language to ensure atomicity.
 430 \end{enumerate*}
 431
 432 As \gls{MTASK} is integrated with \gls{ITASK}, the same stability distinction is made for task values.
 433 A task in \gls{MTASK} is denoted by the \gls{DSL} type synonym shown in \cref{lst:task_type}.
 434
 435 \begin{lstClean}[label={lst:task_type},caption={Task type in \gls{MTASK}.}]
 436 :: MTask v a :== v (TaskValue a)
 437 :: TaskValue a
 438         = NoValue
 439         | Value a Bool
 440 \end{lstClean}
 441
 442 \subsection{Basic tasks}
 443 The most rudimentary basic tasks are the \cleaninline{rtrn} and \cleaninline{unstable} tasks.
 444 They lift the value from the \gls{MTASK} expression language to the task domain either as a stable value or an unstable value.
 445 There is also a special type of basic task for delaying execution.
 446 The \cleaninline{delay} task---given a number of milliseconds---yields an unstable value while the time has not passed.
 447 Once the specified time has passed, the time it overshot the planned time is yielded as a stable task value.
 448 See \cref{sec:repeat} for an example task using \cleaninline{delay}.
 449
 450 \begin{lstClean}[label={lst:basic_tasks},caption={Function examples in \gls{MTASK}.}]
 451 class rtrn v :: (v t) -> MTask v t
 452 class unstable v :: (v t) -> MTask v t
 453 class delay v :: (v n) -> MTask v n | long v n
 454 \end{lstClean}
 455
 456 \subsubsection{Peripherals}\label{sssec:peripherals}
 457 For every sensor or actuator, basic tasks are available that allow interaction with the specific peripheral.
 458 The type classes for these tasks are not included in the \cleaninline{mtask} class collection as not all devices nor all language interpretations have such peripherals connected.
 459 %\todo{Historically, peripheral support has been added \emph{by need}.}
 460
 461 \Cref{lst:dht,lst:gpio} show the type classes for \glspl{DHT} sensors and \gls{GPIO} access.
 462 Other peripherals have similar interfaces, they are available in the \cref{sec:aux_peripherals}.
 463 For the \gls{DHT} sensor there are two basic tasks, \cleaninline{temperature} and \cleaninline{humidity}, that---will given a \cleaninline{DHT} object---produce a task that yields the observed temperature in \unit{\celcius} or relative humidity as a percentage as an unstable value.
 464 Currently, two different types of \gls{DHT} sensors are supported, the \emph{DHT} family of sensors connect through $1$-wire protocol and the \emph{SHT} family of sensors connected using \gls{I2C} protocol.
 465 Creating such a \cleaninline{DHT} object is very similar to creating functions in \gls{MTASK} and uses \gls{HOAS} to make it type safe.
 466
 467 \begin{lstClean}[label={lst:dht},caption{The \gls{MTASK} interface for \glspl{DHT} sensors.}]
 468 :: DHT //abstract
 469 :: DHTInfo
 470         = DHT_DHT Pin DHTtype
 471         | DHT_SHT I2CAddr
 472 :: DHTtype = DHT11 | DHT21 | DHT22
 473 class dht v where
 474         DHT :: DHTInfo ((v DHT) -> Main (v b)) -> Main (v b) | type b
 475         temperature :: (v DHT) -> MTask v Real
 476         humidity :: (v DHT) -> MTask v Real
 477
 478 measureTemp :: Main (MTask v Real) | mtask v & dht v
 479 measureTemp = DHT (DHT_SHT (i2c 0x36)) \dht->
 480         {main=temperature dht}
 481 \end{lstClean}
 482
 483 \Gls{GPIO} access is divided into three classes: analog, digital and pin modes.
 484 For all pins and pin modes an \gls{ADT} is available that enumerates the pins.
 485 The analog \gls{GPIO} pins of a microcontroller are connected to an \gls{ADC} that translates the voltage to an integer.
 486 Analog \gls{GPIO} pins can be either read or written to.
 487 Digital \gls{GPIO} pins only report a high or a low value.
 488 The type class definition is a bit more complex since analog \gls{GPIO} pins can be used as digital \gls{GPIO} pins as well.
 489 Therefore, if the \cleaninline{p} type implements the \cleaninline{pin} class---i.e.\ either \cleaninline{APin} or \cleaninline{DPin}---the \cleaninline{dio} class can be used.
 490 \Gls{GPIO} pins usually operate according to a certain pin mode that states whether the pin acts as an input pin, an input with an internal pull-up resistor or an output pin.
 491 This setting can be applied using the \cleaninline{pinMode} class by hand or by using the \cleaninline{declarePin} \gls{GPIO} pin constructor.
 492 Setting the pin mode is a task that immediately finisheds and fields a stable unit value.
 493 Writing to a pin is also a task that immediately finishes but yields the written value instead.
 494 Reading a pin is a task that yields an unstable value---i.e.\ the value read from the actual pin.
 495
 496 \begin{lstClean}[label={lst:gpio},caption={The \gls{MTASK} interface for \gls{GPIO} access.}]
 497 :: APin = A0 | A1 | A2 | A3 | A4 | A5
 498 :: DPin = D0 | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13
 499 :: PinMode = PMInput | PMOutput | PMInputPullup
 500 :: Pin = AnalogPin APin | DigitalPin DPin
 501 class pin p :: p -> Pin
 502
 503 class aio v where
 504         writeA :: (v APin) (v Int) -> MTask v Int
 505         readA :: (v APin) -> MTask v Int
 506
 507 class dio p v | pin p where
 508         writeD :: (v p) (v Bool) -> MTask v Bool
 509         readD :: (v p) -> MTask v Bool | pin p
 510
 511 class pinMode v where
 512         pinMode :: (v PinMode) (v p) -> MTask v () | pin p
 513         declarePin :: p PinMode ((v p) -> Main (v a)) -> Main (v a) | pin p
 514 \end{lstClean}
 515
 516 \begin{lstClean}[label={lst:gpio_examples},caption={\Gls{GPIO} example in \gls{MTASK}.}]
 517 task1 :: MTask v Int | mtask v
 518 task1 = declarePin A3 PMInput \a3->{main=readA a3}
 519
 520 task2 :: MTask v Int | mtask v
 521 task2 = declarePin D3 PMOutput \d3->{main=writeD d3 true}
 522 \end{lstClean}
 523
 524 \subsection{Task combinators}
 525 Task combinators are used to combine multiple tasks into one to describe workflows.
 526 There are three main types of task combinators, namely:
 527 \begin{enumerate*}
 528         \item Sequential combinators that execute tasks one after the other, possibly using the result of the left hand side.
 529         \item Parallel combinators that execute tasks at the same time combining the result.
 530         \item Miscellaneous combinators that change the semantics of a task---e.g.\ repeat it or delay execution.
 531 \end{enumerate*}
 532
 533 \subsubsection{Sequential}
 534 Sequential task combination allows the right-hand side task to observe the left-hand side task value.
 535 All seqential task combinators are expressed in the \cleaninline{expr} class and can be---and are by default---derived from the Swiss army knife step combinator \cleaninline{>>*.}.
 536 This combinator has a single task on the left-hand side and a list of \emph{task continuations} on the right-hand side.
 537 The list of task continuations is checked every rewrite step and if one of the predicates matches, the task continues with the result of this combination.
 538 \cleaninline{>>=.} is a shorthand for the bind operation, if the left-hand side is stable, the right-hand side function is called to produce a new task.
 539 \cleaninline{>>|.} is a shorthand for the sequence operation, if the left-hand side is stable, it continues with the right-hand side task.
 540 The \cleaninline{>>~.} and \cleaninline{>>..} combinators are variants of the ones above that ignore the stability and continue on an unstable value as well.
 541
 542 \begin{lstClean}[label={lst:mtask_sequential},caption={Sequential task combinators in \gls{MTASK}.}]
 543 class step v | expr v where
 544         (>>*.) infixl 1 :: (MTask v t) [Step v t u] -> MTask v u
 545         (>>=.) infixl 0 :: (MTask v t) ((v t) -> MTask v u) -> MTask v u
 546         (>>|.) infixl 0 :: (MTask v t)          (MTask v u) -> MTask v u
 547         (>>~.) infixl 0 :: (MTask v t) ((v t) -> MTask v u) -> MTask v u
 548         (>>..) infixl 0 :: (MTask v t)          (MTask v u) -> MTask v u
 549
 550 :: Step v t u
 551         = IfValue    ((v t) -> v Bool) ((v t) -> MTask v u)
 552         | IfStable   ((v t) -> v Bool) ((v t) -> MTask v u)
 553         | IfUnstable ((v t) -> v Bool) ((v t) -> MTask v u)
 554         | Always                                (MTask v u)
 555 \end{lstClean}
 556
 557 \todo{more examples step?}
 558
 559 The following listing shows an example of a step in action.
 560 The \cleaninline{readPinBin} function produces an \gls{MTASK} task that classifies the value of an analogue pin into four bins.
 561 It also shows that the nature of embedding allows the host language to be used as a macro language.
 562 Furthermore
 563
 564 \begin{lstClean}[label={lst:mtask_readpinbin},caption={Read an analog pin and bin the value in \gls{MTASK}.}]
 565 readPinBin :: Int -> Main (MTask v Int) | mtask v
 566 readPinBin lim = declarePin PMInput A2 \a2->
 567         { main = readA a2 >>*.
 568                 [  IfValue (\x->x <. lim) (\_->rtrn (lit bin))
 569                 \\ lim <-[64,128,192,256]
 570                 &  bin <- [0..]]}
 571 \end{lstClean}
 572
 573 \subsubsection{Parallel}\label{sssec:combinators_parallel}
 574 The result of a parallel task combination is a compound that actually executes the tasks at the same time.
 575
 576 There are two types of parallel task combinators (see \cref{lst:mtask_parallel}).
 577 The conjunction combinator (\cleaninline{.&&.}) combines the result by putting the values from both sides in a tuple.
 578 The stability of the task depends on the stability of both children.
 579 If both children are stable, the result is stable, otherwise the result is unstable.
 580 The disjunction combinator (\cleaninline{.\|\|.}) combines the results by picking the leftmost, most stable task.
 581 The semantics are easily described using \gls{CLEAN} functions shown in \cref{lst:semantics_con,lst:semantics_dis}.
 582
 583 \begin{figure}[ht]
 584         \centering
 585         \begin{subfigure}[t]{.5\textwidth}
 586                 \begin{lstClean}[caption={Semantics of the\\conjunction combinator.},label={lst:semantics_con}]
 587 con :: (TaskValue a) (TaskValue b)
 588         -> TaskValue (a, b)
 589 con NoValue r       = NoValue
 590 con l       NoValue = NoValue
 591 con (Value l ls) (Value r rs)
 592         = Value (l, r) (ls && rs)
 593
 594                 \end{lstClean}
 595         \end{subfigure}%
 596         \begin{subfigure}[t]{.5\textwidth}
 597                 \begin{lstClean}[caption={Semantics of the\\disjunction combinator.},label={lst:semantics_dis}]
 598 dis :: (TaskValue a) (TaskValue a)
 599         -> TaskValue a
 600 dis NoValue r       = r
 601 dis l       NoValue = l
 602 dis (Value l ls) (Value r rs)
 603         | rs        = Value r True
 604         | otherwise = Value l ls
 605                 \end{lstClean}
 606         \end{subfigure}
 607 \end{figure}
 608
 609 \begin{lstClean}[label={lst:mtask_parallel},caption={Parallel task combinators in \gls{MTASK}.}]
 610 class (.&&.) infixr 4 v :: (MTask v a) (MTask v b) -> MTask v (a, b)
 611 class (.||.) infixr 3 v :: (MTask v a) (MTask v a) -> MTask v a
 612 \end{lstClean}
 613
 614 \Cref{lst:mtask_parallel_example} gives an example of the parallel task combinator.
 615 This program will read two pins at the same time, returning when one of the pins becomes \arduinoinline{HIGH}.
 616 If the combinator was the \cleaninline{.&&.} instead, the type would be \cleaninline{MTask v (Bool, Bool)} and the task would only return when both pins have been \arduinoinline{HIGH} but not necessarily at the same time.
 617
 618 \begin{lstClean}[label={lst:mtask_parallel_example},caption={Parallel task combinator example in \gls{MTASK}.}]
 619 task :: MTask v Bool
 620 task =
 621         declarePin D0 PMInput \d0->
 622         declarePin D1 PMInput \d1->
 623         let monitor pin = readD pin >>*. [IfValue (\x->x) \x->rtrn x]
 624         In {main = monitor d0 .||. monitor d1}
 625 \end{lstClean}
 626
 627 \subsubsection{Repeat}\label{sec:repeat}
 628 The \cleaninline{rpeat} combinator executes the child task.
 629 If a stable value is observed, the task is reinstated.
 630 The functionality of \cleaninline{rpeat} can also be simulated by using functions and sequential task combinators and even made to be stateful as can be seen in \cref{lst:blinkthreadmtask}.
 631
 632 \begin{lstClean}[label={lst:mtask_repeat},caption={Repeat task combinators in \gls{MTASK}.}]
 633 class rpeat v where
 634         rpeat :: (MTask v a) -> MTask v a
 635 \end{lstClean}
 636
 637 To demonstrate the combinator, \cref{lst:mtask_repeat_example} show \cleaninline{rpeat} in use.
 638 This task will mirror the value read from analog \gls{GPIO} pin \cleaninline{A1} to pin \cleaninline{A2} by constantly reading the pin and writing the result.
 639
 640 \begin{lstClean}[label={lst:mtask_repeat_example},caption={Exemplatory repeat task in \gls{MTASK}.}]
 641 task :: MTask v Int | mtask v
 642 task =
 643         declarePin A1 PMInput \a1->
 644         declarePin A2 PMOutput \a2->
 645         {main = rpeat (readA a1 >>~. writeA a2 >>|. delay (lit 1000))}
 646 \end{lstClean}
 647
 648 \subsection{\texorpdfstring{\Glsxtrlongpl{SDS}}{Shared data sources}}
 649 \Glspl{SDS} in \gls{MTASK} are by default references to shared memory but can also be references to \glspl{SDS} in \gls{ITASK} (see \cref{sec:liftsds}).
 650 Similar to peripherals (see \cref{sssec:peripherals}), they are constructed at the top level and are accessed through interaction tasks.
 651 The \cleaninline{getSds} task yields the current value of the \gls{SDS} as an unstable value.
 652 This behaviour is similar to the \cleaninline{watch} task in \gls{ITASK}.
 653 Writing a new value to an \gls{SDS} is done using \cleaninline{setSds}.
 654 This task yields the written value as a stable result after it is done writing.
 655 Getting and immediately after setting an \gls{SDS} is not necessarily an \emph{atomic} operation in \gls{MTASK} because it is possible that another task accesses the \gls{SDS} in between.
 656 To circumvent this issue, \cleaninline{updSds} is created, this task atomically updates the value of the \gls{SDS}.
 657 The \cleaninline{updSds} task only guarantees atomicity within \gls{MTASK}.
 658
 659 \begin{lstClean}[label={lst:mtask_sds},caption={\Glspl{SDS} in \gls{MTASK}.}]
 660 :: Sds a // abstract
 661 class sds v where
 662         sds :: ((v (Sds t)) -> In t (Main (MTask v u))) -> Main (MTask v u)
 663         getSds :: (v (Sds t))                -> MTask v t
 664         setSds :: (v (Sds t))  (v t)         -> MTask v t
 665         updSds :: (v (Sds t)) ((v t) -> v t) -> MTask v t
 666 \end{lstClean}
 667
 668 \Cref{lst:mtask_sds_examples} shows an example using \glspl{SDS}.
 669 The \cleaninline{count} function takes a pin and returns a task that counts the number of times the pin is observed as high by incrementing the \cleaninline{share} \gls{SDS}.
 670 In the \cleaninline{main} expression, this function is called twice and the results are combined using the parallel or combinator (\cleaninline{.||.}).
 671 Using a sequence of \cleaninline{getSds} and \cleaninline{setSds} would be unsafe here because the other branch might write their old increment value immediately after writing, effectively missing a count.\todo{beter opschrijven}
 672
 673 \begin{lstClean}[label={lst:mtask_sds_examples},caption={Examples with \glspl{SDS} in \gls{MTASK}.}]
 674 task :: MTask v Int | mtask v
 675 task = declarePin D3 PMInput \d3->
 676         declarePin D5 PMInput \d5->
 677            sds \share=0
 678         In fun \count=(\pin->
 679                     readD pin
 680                 >>* [IfValue (\x->x) (\_->updSds (\x->x +. lit 1) share)]
 681                 >>| delay (lit 100) // debounce
 682                 >>| count pin)
 683         In {main=count d3 .||. count d5}
 684 \end{lstClean}
 685
 686 \chapter{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}%
 687 \label{chp:integration_with_itask}
 688 \begin{chapterabstract}
 689         This chapter shows the integration with \gls{ITASK}.
 690         It gives an intuition for the architecture of the \gls{IOT} systems.
 691         The interface for connecting devices, lifting \gls{MTASK} tasks to \gls{ITASK} tasks and lifting \gls{ITASK} \glspl{SDS} to \gls{MTASK} \glspl{SDS} is shown.
 692 \end{chapterabstract}
 693
 694 The \gls{MTASK} language is a multi-view \gls{DSL}, i.e.\ there are multiple interpretations possible for a single \gls{MTASK} term.
 695 Using the byte code compiler (\cleaninline{BCInterpret}) \gls{DSL} interpretation, \gls{MTASK} tasks can be fully integrated in \gls{ITASK}.
 696 They are executed as if they are regular \gls{ITASK} tasks and they communicate may access \glspl{SDS} from \gls{ITASK} as well.
 697 \Gls{MTASK} devices contain a domain-specific \gls{OS} (\gls{RTS}) and are little \gls{TOP} engines in their own respect, being able to execute tasks.
 698 \Cref{fig:mtask_integration} shows the architectural layout of a typical \gls{IOT} system created with \gls{ITASK} and \gls{MTASK}.
 699 The entire system is written as a single \gls{CLEAN} specification where multiple tasks are executed at the same time.
 700 Tasks can access \glspl{SDS} according to many-to-many communication and multiple clients can work on the same task.
 701 Devices are integrated into the system using the \cleaninline{withDevice} function (see \cref{sec:withdevice}).
 702 Using \cleaninline{liftmTask}, \gls{MTASK} tasks are lifted to a device (see \cref{sec:liftmtask}).
 703 \Gls{ITASK} \glspl{SDS} are lifted to the \gls{MTASK} device using \cleaninline{liftsds} (see \cref{sec:liftmtask}).
 704
 705 \begin{figure}[ht]
 706         \centering
 707         \includestandalone{mtask_integration}
 708         \caption{\Gls{MTASK}'s integration with \gls{ITASK}.}%
 709         \label{fig:mtask_integration}
 710 \end{figure}
 711
 712 \section{Devices}\label{sec:withdevice}
 713 When interpreted by the byte code compiler view, an \gls{MTASK} task produces a compiler.
 714 This compiler is exceuted at run time so that the resulting byte code can be sent to an edge device.
 715 All communication with this device happens through a so-called \emph{channels} \gls{SDS}.
 716 The channels contain three fields, a queue of messages that are received, a queue of messages to send and a stop flag.
 717 Every communication method that implements the \cleaninline{channelSync} class can provide the communication with an \gls{MTASK} device.
 718 As of now, serial port communication, direct \gls{TCP} communication and \gls{MQTT} over \gls{TCP} are supported as communication providers.
 719 The \cleaninline{withDevice} function transforms a communication provider and a task that does something with this device to an \gls{ITASK} task.
 720 This task sets up the communication, exchanges specifications, handles errors and cleans up after closing.
 721 \Cref{lst:mtask_device} shows the types and interface to connecting devices.
 722
 723 \begin{lstClean}[label={lst:mtask_device},caption={Device communication interface in \gls{MTASK}.}]
 724 :: MTDevice //abstract
 725 :: Channels :== ([MTMessageFro], [MTMessageTo], Bool)
 726
 727 class channelSync a :: a (sds () Channels Channels) -> Task () | RWShared sds
 728
 729 withDevice :: (a (MTDevice -> Task b) -> Task b) | iTask b & channelSync, iTask a
 730 \end{lstClean}
 731
 732 \section{Lifting tasks}\label{sec:liftmtask}
 733 Once the connection with the device is established, \ldots
 734 \begin{lstClean}
 735 liftmTask :: (Main (BCInterpret (TaskValue u))) MTDevice -> Task u | iTask u
 736 \end{lstClean}
 737
 738 \section{Lifting \texorpdfstring{\glsxtrlongpl{SDS}}{shared data sources}}\label{sec:liftsds}
 739 \begin{lstClean}[label={lst:mtask_itasksds},caption={Lifted \gls{ITASK} \glspl{SDS} in \gls{MTASK}.}]
 740 class liftsds v where
 741         liftsds :: ((v (Sds t))->In (Shared sds t) (Main (MTask v u)))
 742                 -> Main (MTask v u) | RWShared sds
 743 \end{lstClean}
 744
 745 \chapter{Implementation}%
 746 \label{chp:implementation}
 747 \begin{chapterabstract}
 748         This chapter shows the implementation of the \gls{MTASK} system.
 749         It is threefold: first it shows the implementation of the byte code compiler for \gls{MTASK}'s \gls{TOP} language, then is details of the implementation of \gls{MTASK}'s \gls{TOP} engine that executes the \gls{MTASK} tasks on the microcontroller, and finally it shows how the integration of \gls{MTASK} tasks and \glspl{SDS} is implemented both on the server and on the device.
 750 \end{chapterabstract}
 751 IFL19 paper, bytecode instructieset~\cref{chp:bytecode_instruction_set}
 752
 753 \section{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}
 754 IFL18 paper stukken
 755
 756 \chapter{Green computing with \texorpdfstring{\gls{MTASK}}{mTask}}%
 757 \label{chp:green_computing_mtask}
 758 \begin{chapterabstract}
 759         This chapter demonstrate the energy saving features of \gls{MTASK}.
 760         First it gives an overview of general green computing measures for edge devices.
 761         Then \gls{MTASK}'s task scheduling is explained and it is shown how to customise it so suit the applications and energy needs.
 762         Finally it shows how to use interrupts in \gls{MTASK} to reduce the need for polling.
 763 \end{chapterabstract}
 764
 765 \section{Green \texorpdfstring{\glsxtrshort{IOT}}{IoT} computing}
 766
 767 \section{Task scheduling}
 768 \subsection{Language}
 769 \subsection{Device}
 770
 771 \section{Interrupts}
 772
 773 \input{subfilepostamble}
 774 \end{document}