\chapter{\texorpdfstring{\Glsxtrlong{TOP} for the \glsxtrlong{IOT}}{Task-oriented programming for the internet of things}}%
\label{chp:top4iot}
\begin{chapterabstract}
- This chapter compares traditional edge device programming to \gls{TOP} by:
+ \noindent This chapter introduces the monograph. It compares traditional edge device programming to \gls{TOP} by:
\begin{itemize}
\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 multithreading, uncovering problems using \gls{ARDUINO};
- \item and demonstrating that upgrading to a multi-tasking variant is straightforward using \gls{MTASK}.
+ \item extending the idea to cooperative multitasking, uncovering problems using \gls{ARDUINO};
+ \item demonstrating that upgrading to a multi-tasking variant is straightforward using \gls{MTASK};
+ \item elaborating on integrating an edge device program with a server;
+ \item and providing a reading guide for the rest of the monograph.
\end{itemize}
\end{chapterabstract}
The edge layer of \gls{IOT} systems predominantly consists of microcontrollers.
-Microcontrollers are tiny computers designed specifically for embedded applications that much from regular computers in all aspects.
+Microcontrollers are tiny computers designed specifically for embedded applications that differ much from regular computers in all aspects.
They are much smaller; only have a fraction of the memory and processor speed; and run on different architectures.
However, they have much more energy-efficient sleep modes, and support connecting and interfacing with peripherals such as sensors and actuators.
\Cref{tbl:mcu_laptop} compares the hardware properties of a typical laptop with two very popular microcontrollers.
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}.
-To structure this jungle of tools, platforms exist that provide abstraction layers over the low-level toolchains such as \gls{ARDUINO}.
+To structure this jungle of tools, platforms exist that provide abstraction layers over the low-level toolchains such as \gls{ARDUINO}\footnote{\refurl{https://www.arduino.cc}{\formatdate{19}{12}{2022}}}.
It is specifically designed for education and prototyping and hence used here to illustrate traditional microcontroller programming.
The popular \gls{ARDUINO} \ccpp{} 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 by vendor-provided \emph{cores}.
It provides an \gls{IDE} and toolchain automation to perform all steps of the toolchain with a single command.
\section{\texorpdfstring{\Glsxtrshort{TOP} for the \glsxtrshort{IOT}}{TOP for the IoT}}
-\Gls{TOP} is a programming paradigm that allows multi-tier interactive systems to be generated from a single declarative source.
-\Gls{ITASK} is a general-purpose \gls{TOP} system for programming interactive distributed web applications.
-These distributed web applications often form the core of the top two layers of \gls{IOT} applications.
-Integrating the perception layer, the edge devices, in \gls{ITASK} also is not straightforward.
-\Gls{ITASK} targets relatively fast but 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 functional programs that \gls{ITASK} programs are.
-\Gls{MTASK} bridges this gap by providing a \gls{TOP} \gls{DSL} for \gls{IOT} edge devices.
-Domain-specific knowledge is embedded in the language and execution platform, drastically lowering the hardware requirements.
-The following sections compare traditional microcontroller programming with programming the devices using \gls{MTASK}.
+\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.
+Interactive distributed web applications often form the core of the top two layers of \gls{IOT} applications.
+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 in \gls{ITASK} however is not straightforward.
+\Gls{ITASK} targets 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 \gls{TOP} \gls{DSL} 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 lowere the hardware requirements.\todo{beter?}
\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.
Microcontrollers usually do not come with screens in the traditional sense.
-Nevertheless, almost always there is a built-in monochrome \numproduct{1x1} pixel screen, namely the built-in \gls{LED}. %chktex 29
+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}.
-Using \gls{ARDUINO}'s \ccpp{} dialect to create the blink program results in the code seen in \citelisting{\ref{lst:arduinoBlink}}.
+Using \gls{ARDUINO}'s \ccpp{} dialect to create the blink program results 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.
In the blink example, the \arduinoinline{setup} function only contains code for setting the \gls{GPIO} pin to the correct mode.
}\end{lstArduino}
\subsection{Blinking the \texorpdfstring{\glsxtrshort{LED}}{LED} in \texorpdfstring{\gls{MTASK}}{mTask}.}
-Naively translating the traditional blink program to \gls{MTASK} can be done by simply substituting some syntax as seen in \citelisting{\ref{lst:blinkImp}}.
+Naively translating the traditional blink program to \gls{MTASK} can 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.
-\begin{lstClean}[caption={Blinking the \gls{LED}.},label={lst:blinkImp}]
-blink :: Main (MTask v ()) | mtask v
-blink =
- declarePin D2 PMOutput \d2->
+
+\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}
+However, as \gls{MTASK} is hosted in a full fledged functional language, it is also possible to define the blinking behaviour as a function.
+\Cref{lst:blinkFun} shows this more natural translation.
+The \cleaninline{main} expression is just 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 same 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 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)
+ >>|. blink (Not st))
+ In {main = blink true}
+\end{lstClean}
+
\section{Multi tasking}
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}.
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);
It has no observable value until the target waiting time has passed, and thence is \emph{stable}.
To make code reuse possible and make the implementation more intuitive, the blinking behaviour is lifted to a recursive function instead of using the imperatively looking \cleaninline{rpeat} task combinator.
There is no global state, the function is parametrized with the current status, 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 are executed in an interleaved fashion.
Therefore, blinking three different blinking patterns is as simple as combining the three calls to the \cleaninline{blink} function with their arguments as seen in \cref{lst:blinkthreadmtask}.
% VimTeX: SynIgnore on
\begin{lstClean}[label={lst:blinkthreadmtask},caption={Threading three blinking patterns.}]
blinktask :: MTask v () | mtask v
-blinktask =
- declarePin D1 PMOutput \d1->
+blinktask = declarePin D1 PMOutput \d1->
declarePin D2 PMOutput \d2->
declarePin D3 PMOutput \d3->
fun \blink=(\(st, pin, wait)->
delay wait
>>|. writeD d13 st
>>|. 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}
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.
With the \gls{MTASK} system, a \gls{TOP} programming language for \gls{IOT} edge devices, this limitation can be overcome.
As much domain-specific knowledge is built into the language and the \gls{RTS}, the hardware requirements can be kept relatively low while maintaining a high abstraction level.
-\todo{moet dit uitgebreider?}
+Furthermore, the programs are automatically integrated with \gls{ITASK}, allowing for data sharing, task coordination, and dynamic construction of tasks.
+
+The following chapters thoroughly introduce all aspects of the \gls{MTASK} system.
+First the language setup and interface is shown in \cref{chp:mtask_dsl}.
+Then the interface for integrating \gls{MTASK} with \gls{ITASK} is provided in \cref{chp:integration_with_itask}.
+\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 the green computing aspects of \gls{MTASK}, i.e.\ task scheduling and processor interrupts.
+Finally, \cref{chp:finale} concludes, and shows related work together with a short history of \gls{MTASK}.
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / blobdiff