\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
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}
repositories / phd-thesis.git / blobdiff