X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=top%2F4iot.tex;h=b864f14bd38a85a172bfe08c0874ab3c989d4c65;hb=529531e1028ae26ab889456d65958794154d5b25;hp=10457ba61f95a88a616c5e6e88bac20ffd58f1e9;hpb=3369704052f2381076b72efb24d57a943172e729;p=phd-thesis.git diff --git a/top/4iot.tex b/top/4iot.tex index 10457ba..b864f14 100644 --- a/top/4iot.tex +++ b/top/4iot.tex @@ -2,32 +2,35 @@ \input{subfilepreamble} +\setcounter{chapter}{3} + \begin{document} \input{subfileprefix} - -\chapter{\texorpdfstring{\Glsxtrlong{TOP} for the \glsxtrlong{IOT}}{Task-oriented programming for the internet of things}}% +\chapter{Task-oriented programming for the internet of things}% \label{chp:top4iot} \begin{chapterabstract} - \noindent This chapter: + This chapter introduces the monograph. It compares traditional edge device programming to \gls{TOP} by: \begin{itemize} - \item introduces the problems with \gls{TOP} for the \gls{IOT}. - \item shows how to create the \emph{Hello World!} application for microcontrollers using \gls{ARDUINO}; - \item extends this idea with multithreading, demonstrating the difficulty programming multi-tasking applications; - \item describes a comparative variant in \gls{MTASK} and shows that upgrading to a multi-tasking variant is straightforward - \item demonstrates that the complexity of running multiple tasks; - \item and concludes with the history of \gls{MTASK}'s development. + \item introducing edge device programming; + \item showing how to create the \emph{Hello World!} application for microcontrollers using \gls{ARDUINO} and \gls{MTASK}; + \item extending the idea to cooperative multitasking, uncovering problems using \gls{ARDUINO} that do not exist in \gls{MTASK}; + \item and providing a reading guide for the remainder of the monograph. \end{itemize} \end{chapterabstract} -The edge layer of \gls{IOT} systems predominantly contains of microcontrollers. +The edge layer of \gls{IOT} systems predominantly consists of microcontrollers. Microcontrollers are tiny computers designed specifically for embedded applications. -They therefore only have a soup\c{c}on of memory, have a slow processor, come with many energy efficient sleep modes and have a lot of peripheral support such as \gls{GPIO} pins. -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. -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. -\Cref{tbl:mcu_laptop} compares the hardware properties of a typical laptop with two very popular microcontrollers. +They differ significantly from regular computers in many aspects, and as a consequence, development for microcontrollers differs also. +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. +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. \begin{table} - \caption{Hardware characteristics of typical microcontrollers compared to laptops.}% + \centering + \caption{Hardware characteristics of a laptop and two typical microcontrollers.}% \label{tbl:mcu_laptop} \begin{tabular}{llll} \toprule @@ -36,212 +39,194 @@ The programs are usually cyclic executives instead of tasks running in an operat CPU speed & \qtyrange{2}{4}{\giga\hertz} & \qty{16}{\mega\hertz} & \qty{80}{\mega\hertz} or \qty{160}{\mega\hertz}\\ \textnumero{} cores & \numrange{4}{8} & 1 & 1\\ Storage & \qty{1}{\tebi\byte} & \qty{32}{\kibi\byte} & \qtyrange{0.5}{4}{\mebi\byte}\\ - \gls{RAM} & \qtyrange{4}{16}{\gibi\byte} & \qty{2}{\kibi\byte} & \qty{160}{\kibi\byte}\\ + \Gls{RAM} & \qtyrange{4}{16}{\gibi\byte} & \qty{2}{\kibi\byte} & \qty{160}{\kibi\byte}\\ Power & \qtyrange{50}{100}{\watt} & \qtyrange{0.13}{250}{\milli\watt} & \qtyrange{0.1}{350}{\milli\watt}\\ Size & $\pm$\qty{1060}{\cubic\cm} & $\pm$\qty{7.5}{\cubic\cm} & $\pm$\qty{1.1}{\cubic\cm}\\ + Display & \numproduct{1920x1080x24} & \numproduct{1x1x1} & \numproduct{1x1x1}\\ %chktex 29 Price & \euro{1500} & \euro{3} & \euro{4}\\ \bottomrule \end{tabular} \end{table} -Different models of microcontrollers require their own vendor-provided drivers, hardware abstraction layer, compilers and \glspl{RTS}. -There are many platforms 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. -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. -Originally it was designed for the in-house developed open-source hardware with the same name but the setup allows porting to many architectures. -It provides an \gls{IDE} and toolchain automation to perform all steps of the toolchain with a single command. - -\subsection{\texorpdfstring{\Glsxtrshort{TOP} for the \glsxtrshort{IOT}}{TOP for the IoT}} -\Gls{TOP} is a programming paradigm that allows multi-tier systems to be generated from a single declarative source. -\Gls{ITASK} is a general-purpose \gls{TOP} system for programming distributed web applications. -These distributed web applications often form the core of \gls{IOT} applications as well but integrating these devices in \gls{ITASK} is not straightforward. -\Gls{ITASK} targets relatively fast but energy-hungry systems with large amounts of \gls{RAM} and a speedy connections. -Edge devices in \gls{IOT} systems are typically slow but energy efficient and do not have the memory to run the naturally heap-heavy functional programs that \gls{ITASK} results in. -\Gls{MTASK} bridges this gap by providing a \gls{TOP} \gls{DSL} for \gls{IOT} edge devices that can, because domain-specific knowledge is built in, run on hardware with much less memory and processor speed. -The following sections compare traditional microcontroller programming with programming the devices using \gls{MTASK}. +All microcontroller models require their own vendor-provided drivers, hardware abstraction layer, compilers and \glspl{RTS}. +To structure this jungle of tools, platforms exist that provide an abstraction layer over the low-level toolchains. +An example of this is the \gls{ARDUINO} environment\footnote{\refurl{https://www.arduino.cc}{\formatdate{19}{12}{2022}}}. +Originally it was designed for the in-house developed open-source hardware with the same name, but the setup allows porting to many architectures by vendor-provided \emph{cores}. +This set of tools is specifically designed for education and prototyping and hence used here to illustrate traditional microcontroller programming. +It consists of an \gls{IDE} containing toolchain automation, a dialect of \ccpp{}, and libraries providing an abstraction layer for microcontroller behaviour. +With \gls{ARDUINO}, the programmer can program multiple types of microcontrollers using a single language. +Using the \gls{IDE} and toolchain automation, code can be executed easily on many types of microcontrollers with a single press of a button. + +\section{TOP for the IoT} +\Gls{TOP} is a programming paradigm that allows multi-tier interactive systems to be generated from a single declarative source (see \cref{sec:back_top}). +An example of a \gls{TOP} system is \gls{ITASK}, a general-purpose \gls{TOP} language for programming interactive distributed web applications. +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. +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. +Programs in \gls{MTASK} are written in the \gls{MTASK} \gls{DSL}, a \gls{TOP} language that offers a similar abstraction level as \gls{ITASK}. +Tasks in \gls{MTASK} operate as if they are \gls{ITASK} tasks, their task value is observable by other tasks, and they can share data using \gls{ITASK} \glspl{SDS}. +This allows for programming entire \gls{IOT} systems from a single abstraction level, source code, and programming paradigm. \section{Hello world!} Traditionally, the first program that one writes when trying a new language is the so-called \emph{Hello World!} program. -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. -On microcontrollers, there usually is no screen for displaying text. -Nevertheless, almost always there is a built-in monochrome $1\times1$ pixel screen, namely \pgls{LED}. +This program has the single task of printing the text \emph{Hello World!} to the screen and exiting again. +It helps the programmer to become familiarised with the syntax of the language and to verify that the toolchain and runtime environment are working. +Microcontrollers usually do not come with screens in the traditional sense. +Nevertheless, almost always there is a built-in 1 pixel screen with a \qty{1}{\bit} color depth, namely the on-board \gls{LED}. The \emph{Hello World!} equivalent on microcontrollers blinks this \gls{LED}. -\Cref{lst:arduinoBlink} shows how the logic of a blink program might look when using \gls{ARDUINO}'s \gls{C}\slash\gls{CPP} dialect. -Every \gls{ARDUINO} program contains a \arduinoinline{setup} and a \arduinoinline{loop} function. +Creating a blink program using \ccpp{} and the \gls{ARDUINO} libraries result in the code seen in \cref{lst:arduinoBlink}. +\Gls{ARDUINO} programs are implemented as cyclic executives and hence, each program defines a \arduinoinline{setup} and a \arduinoinline{loop} function. The \arduinoinline{setup} function is executed only once on boot, the \arduinoinline{loop} function is continuously called afterwards and contains the event loop. -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. -In between it waits for \qty{500}{\ms} so that the blinking is actually visible for the human eye. - -Translating the traditional blink program to \gls{MTASK} can almost be done by simply substituting some syntax as seen in \cref{lst:blinkImp}. -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. -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. -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. -The body of the \cleaninline{rpeat} contains similarly named tasks to write to the pins and to wait in between. -The tasks are connected using the sequential \cleaninline{>>|.} combinator that for all current intents and purposes executes the tasks after each other. +In between the executions of the \arduinoinline{loop} function, system and maintenance code is executed. +In the blink example, the \arduinoinline{setup} function only contains code for setting the \gls{GPIO} pin to the correct mode. +The \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. +In between, it waits \qty{500}{\ms} so that the blinking is actually visible for the human eye. -\begin{figure}[ht] - \begin{subfigure}[b]{.5\linewidth} - \begin{lstArduino}[caption={Blink program.},label={lst:arduinoBlink}] +\begin{lstArduino}[caption={Blinking an \gls{LED}.},label={lst:arduinoBlink}] void setup() { pinMode(D2, OUTPUT); } - void loop() { digitalWrite(D2, HIGH); delay(500); digitalWrite(D2, LOW); delay(500); }\end{lstArduino} - \end{subfigure}% - \begin{subfigure}[b]{.5\linewidth} - \begin{lstClean}[caption={Blink program.},label={lst:blinkImp}] -blink :: Main (MTask v ()) | mtask v -blink = - declarePin D2 PMOutput \d2-> + +\subsection{Blinking the LED in mTask} +Naively translating the traditional blink program to \gls{MTASK} can be done by simply substituting syntax as seen in \cref{lst:blinkImp}. +E.g.\ \arduinoinline{digitalWrite} becomes \cleaninline{writeD}, literals are prefixed with \cleaninline{lit}, and \arduinoinline{pinMode} becomes \arduinoinline{declarePin}. +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. +The task is not the single cyclic executive and therefore consists of just a main expression. +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. + +\begin{lstClean}[caption={Blinking the \gls{LED} using the \cleaninline{rpeat} combinator.},label={lst:blinkImp}] +blinkTask :: Main (MTask v ()) | mtask v +blinkTask = declarePin D2 PMOutput \ledPin-> {main = rpeat ( - writeD d2 true + writeD ledPin true >>|. delay (lit 500) - >>|. writeD d2 false + >>|. writeD ledPin false + >>|. delay (lit 500)) + } +\end{lstClean} + +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{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. + +\begin{lstClean}[caption={Blinking the \gls{LED} using a function.},label={lst:blinkFun}] +blinkTask :: Main (MTask v ()) | mtask v +blinkTask = declarePin D2 PMOutput \ledPin-> + fun \blink=(\st-> + writeD ledPin st >>|. delay (lit 500) - ) -}\end{lstClean} - \end{subfigure} -\end{figure} + >>|. blink (Not st)) + In {main = blink true} +\end{lstClean} -\section{Multi tasking} +\section{Multitasking} Now say that we want to blink multiple blinking patterns on different \glspl{LED} concurrently. For example, blink three \glspl{LED} connected to \gls{GPIO} pins $1,2$ and $3$ at intervals of \qtylist{500;300;800}{\ms}. -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} +Intuitively, you would want to lift the blinking behaviour to a function in order to minimise duplicate code, and increase modularity by calling this function three times with different parameters as shown in \cref{lst:blinkthreadno}. \begin{lstArduino}[caption={Naive approach to multiple blinking patterns.},label={lst:blinkthreadno}] void setup () { ... } - -void blink (int pin, int wait) { +void blink(int pin, int wait) { digitalWrite(pin, HIGH); delay(wait); digitalWrite(pin, LOW); delay(wait); } - void loop() { blink (D1, 500); blink (D2, 300); blink (D3, 800); }\end{lstArduino} -Unfortunately, this does not work because the \arduinoinline{delay} function blocks all further execution. -The resulting program will blink the \glspl{LED} after each other instead of at the same time. -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}. -Listing~\ref{lst:blinkthread} shows how three different blinking patterns might be achieved in \gls{ARDUINO} using the slicing method. -If we want the blink function to be a separate parametrizable function we need to explicitly provide all references to the required state. +Unfortunately, this does not work because the \arduinoinline{delay} function blocks all other execution. +The resulting program blinks the \glspl{LED} after each other instead of at the same time. +To overcome this, it is necessary to slice up the blinking behaviour in small fragments and interleave it manually \citep{feijs_multi-tasking_2013}. +\Cref{lst:blinkthread} shows how three different blinking patterns could be implemented in \gls{ARDUINO} using the slicing method. +If we want the blink function to be a separate parametrisable function we need to explicitly provide all references to the required global state. Furthermore, the \arduinoinline{delay} function can not be used and polling \arduinoinline{millis} is required. The \arduinoinline{millis} function returns the number of milliseconds that have passed since the boot of the microcontroller. -Some devices use very little energy when in \arduinoinline{delay} or sleep state. -Resulting in \arduinoinline{millis} potentially affects power consumption since the processor is basically busy looping all the time. -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. +If the delay passed to the \arduinoinline{delay} function is long enough, the firmware may decide to put the processor in sleep mode, reducing the power consumption drastically. +When polling \arduinoinline{millis} is used, this therefore potentially affects power consumption since the processor is busy looping all the time, not knowing when to go to sleep. +Manually combining tasks into a single modular program is very error-prone, requires a lot of pointer juggling, and generally results into spaghetti code. +Furthermore, it is very difficult to represent dependencies between threads. +Often state machines have to be explicitly programmed and merged by hand to achieve this. +In the simple case of blinking three \glspl{LED} according to fixed intervals, it is possible to calculate the delays in advance using static analysis and generate the appropriate \arduinoinline{delay} calls. Unfortunately, this is very hard when for example the blinking patterns are determined at runtime. \begin{lstArduino}[label={lst:blinkthread},caption={Threading three blinking patterns.}] -long led1 = 0, led2 = 0, led3 = 0; +long led1 = 0, led2 = 0, led3 = 0; bool st1 = false, st2 = false, st3 = false; +void setup () { ... } void blink(int pin, int interval, long *lastrun, bool *st) { if (millis() - *lastrun > interval) { digitalWrite(pin, *st = !*st); *lastrun += interval; } } - void loop() { blink(D1, 500, &led1, &st1); blink(D2, 300, &led2, &st1); blink(D3, 800, &led3, &st1); }\end{lstArduino} -This method is very error prone, requires a lot of pointer juggling and generally results into spaghetti code. -Furthermore, it is very difficult to represent dependencies between threads, often state machines have to be explicitly programmed by hand to achieve this. - -\subsection{Multi tasking in \texorpdfstring{\gls{MTASK}}{mTask}} -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. -In contrast, the \arduinoinline{delay()} \emph{function} on the \gls{ARDUINO} is blocking which prohibits interleaving. -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. -The function is parametrized with the current state, the pin to blink and the waiting time. -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. -With a parallel combinator, tasks can be executed in an interleaved fashion. +\subsection{Multitasking in mTask} +In contrast to the \arduinoinline{delay} function in \gls{ARDUINO}, \gls{MTASK}'s \cleaninline{delay} \emph{task} 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. 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={Threaded blinking.}] +\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 >>|. blink (Not st, pin, wait)) - In {main = - blink (true, d1, lit 500) - .||. blink (true, d2, lit 300) - .||. blink (true, d3, lit 800) + In {main = blink (true, d1, lit 500) + .||. blink (true, d2, lit 300) + .||. blink (true, d3, lit 800) } \end{lstClean} % VimTeX: SynIgnore off -\section{Conclusion} +\section{Conclusion and reading guide} +This chapter introduced traditional edge device programming and programming edge devices using \gls{MTASK}. 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. -Due to the lack of an \gls{OS}, writing applications that perform multiple tasks at the same time is error prone, and complex; and requires a lot of boilerplate and manual scheduling code. +Due to the lack of an \gls{OS}, writing applications that perform multiple tasks at the same time is error-prone, becomes complex, and requires a lot of boilerplate such as manual scheduling code. With the \gls{MTASK} system, a \gls{TOP} programming language for \gls{IOT} edge devices, this limitation can be overcome. -\todo{uit\-breiden} - -\begin{subappendices} -\section{History of \texorpdfstring{\gls{MTASK}}{mTask}} -The development of \gls{MTASK} or its predecessors has been going on for almost seven years now though it really set off during my master's thesis. -This section provides an exhaustive overview of the work on \gls{MTASK} and its predecessors. - -\subsection*{Generating \texorpdfstring{\gls{C}/\gls{CPP}}{C/C++} code} -A first throw at a class-based shallowly \gls{EDSL} for microcontrollers was made by \citet{plasmeijer_shallow_2016}. -The language was called \gls{ARDSL} and offered a type safe interface to \gls{ARDUINO} \gls{CPP} dialect. -A \gls{CPP} code generation backend was available together with an \gls{ITASK} simulation backend. -There was no support for tasks nor even functions. -Some time later in the 2015 \gls{CEFP} summer school, an extended version was created that allowed the creation of imperative tasks, local \glspl{SDS} and the usage of functions \citep{koopman_type-safe_2019}. -The name then changed from \gls{ARDSL} to \gls{MTASK}. - -\subsection*{Integration with \texorpdfstring{\gls{ITASK}}{iTask}} -\Citet{lubbers_task_2017} extended this in his Master's Thesis by adding integration with \gls{ITASK} and a bytecode compiler to the language. -\Gls{SDS} in \gls{MTASK} could be accessed on the \gls{ITASK} server. -In this way, entire \gls{IOT} systems could be programmed from a single source. -However, this version used a simplified version of \gls{MTASK} without functions. -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}. -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. -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}. - -\subsection*{Transition to \texorpdfstring{\gls{TOP}}{TOP}} -The \gls{MTASK} language as it is now was introduced in 2018 \citep{koopman_task-based_2018}. -This paper updated the language to support functions, simple tasks, and \glspl{SDS} but still compiled to \gls{ARDUINO} \gls{CPP} code. -Later the byte code compiler and \gls{ITASK} integration was added to the language \citep{lubbers_interpreting_2019}. -Moreover, it was shown that it is very intuitive to write microcontroller applications in a \gls{TOP} language \citep{lubbers_multitasking_2019}. -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). -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}. - -\subsection*{\texorpdfstring{\Glsxtrshort{TOP}}{TOP}} -In 2022, the SusTrainable summer school in Rijeka, Croatia hosted a course on developing greener \gls{IOT} applications using \gls{MTASK} as well \citep{lubbers_green_2022}. -Several students worked on extending \gls{MTASK} with many useful features: -\Citet{van_der_veen_mutable_2020} did preliminary work on a green computing analysis, built a simulator, and explored the possibilities for adding bounded datatypes; \citet{de_boer_secure_2020} investigated the possibilities for secure communication channels; \citeauthor{crooijmans_reducing_2021} \citeyearpar{crooijmans_reducing_2021,crooijmans_reducing_2022} added abstractions for low-power operation to \gls{MTASK} such as hardware interrupts and power efficient scheduling; and \citet{antonova_mtask_2022} defined a preliminary formal semantics for a subset of \gls{MTASK}. - -\subsection*{\texorpdfstring{\gls{MTASK}}{mTask} in practise} -Funded by the Radboud-Glasgow Collaboration Fund, collaborative work was executed with Phil Trinder, Jeremy Singer, and Adrian Ravi Kishore Ramsingh. -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}. -This research was later extended to include a four-way comparison: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK}, and \gls{MTASK} \citep{lubbers_could_2022}. -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. - -\subsection*{Future work} -Plans for extensions and improvements include exploring integrating \gls{TINYML} into \gls{MTASK}; adding intermittent computing support to \gls{MTASK}; and extending the formal semantics to cover the entirety of the language. -In 2023, the SusTrainable summer school in Coimbra, Portugal will host a course on \gls{MTASK} as well. - -\end{subappendices} +Since much domain-specific knowledge is built into the language and \gls{RTS}, the hardware requirements can be kept relatively low while maintaining a high abstraction level. +Furthermore, the programs are automatically integrated with \gls{ITASK}, a \gls{TOP} system for creating interactive distributed web applications, allowing for data sharing, task coordination, and dynamic construction of tasks. + +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}. +\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. +Finally, \cref{chp:finale} concludes, shows related work, and provides a short history of \gls{MTASK}. \input{subfilepostamble} \end{document}