\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.
+ \item and concluding with a reading guide for the remainder of the monograph.
\end{itemize}
\end{chapterabstract}
They differ significantly from regular computers in many aspects.
For example, they are much smaller; only have a fraction of the memory and processor speed; and run on different architectures.
Furthermore, they have much more energy-efficient sleep modes, and support connecting and interfacing with peripherals such as sensors and actuators.
-To illustrate the difference in characteristics, \cref{tbl:mcu_laptop} compares the hardware properties of a typical laptop with two popular microcontrollers.
-As a consequence of these differences, development for microcontrollers is also unlike development for traditional computers.
-Usually, programming microcontrollers requires an elaborate multistep toolchain of compilation, linkage, binary image creation, and burning this image onto the flash memory of the microcontroller in order to run a program.
-The software is usually a cyclic executive instead of tasks that run in an \gls{OS}.
+To illustrate the difference in characteristics, \cref{tbl:mcu_laptop} compares the hardware properties of a typical laptop to the characteristics two popular microcontrollers.
+As a consequence of these differences, development for microcontrollers is unlike development for traditional computers.
+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.
+Furthermore, as there is no \gls{OS} to coordinate multiple tasks running at the same time, the software is usually written as a cyclic executive.
Hence, all tasks must be manually combined into a single program.
\begin{table}
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.
-All \gls{ITASK} applications carry the weigth of multi-user \gls{TOP} programs that can generically generate webpages, communication, and storage for all data types in the program.
-As a result, the \gls{ITASK} system targetting relatively fast and hence energy-hungry systems with large amounts of \gls{RAM} and a speedy connection.
+All \gls{ITASK} applications carry the weight of multi-user \gls{TOP} programs that can generically generate webpages, communication, and storage for all data types in the program.
+As a result, the \gls{ITASK} system targeting 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.
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}.
+The \emph{Hello World!} equivalent for microcontrollers blinks this \gls{LED}.
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.
\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->
+ fun \blink = (\st->
writeD ledPin st
>>|. delay (lit 500)
>>|. blink (Not st))
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 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}]
+\begin{lstArduino}[float=,caption={Naive approach to multiple blinking patterns.},label={lst:blinkthreadno}]
void setup () { ... }
void blink(int pin, int wait) {
digitalWrite(pin, HIGH);
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.
-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.}]
+\begin{lstArduino}[float=,label={lst:blinkthread},caption={Threading three blinking patterns.}]
long led1 = 0, led2 = 0, led3 = 0;
bool st1 = false, st2 = false, st3 = false;
blink(D3, 800, &led3, &st1);
}\end{lstArduino}
+\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.
+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.
+
\subsection{Multitasking in mTask}
In \gls{MTASK}, expressions are eagerly evaluated in an interpreter and tasks are executed by small-step rewrite rules.
-In between these rewrite steps, other tasks are be executed and communication is handled.
+In between these rewrite steps, other tasks are executed and communication is handled.
Consequently, and in contrast to \gls{ARDUINO}, the \cleaninline{delay} task in \gls{MTASK} does not block the execution.
It has no observable value until the target waiting time has passed, and is thence \emph{stable}.
As there is no global state, the function is parametrised with the current status, the pin to blink and the waiting time.
-With a parallel combinator, tasks are executed seamingly at the same time, i.e.\ their very short small-step reduction steps are interleaved.
+With a parallel combinator, tasks are executed seemingly at the same time, i.e.\ their very short small-step reduction steps are interleaved.
Therefore, blinking three different blinking patterns is as simple as combining the three calls to the \cleaninline{blink} function with their arguments as seen in \cref{lst:blinkthreadmtask}.
% VimTeX: SynIgnore on
declarePin D1 PMOutput \d1->
declarePin D2 PMOutput \d2->
declarePin D3 PMOutput \d3->
- fun \blink=(\(st, pin, wait)->
+ fun \blink = (\(st, pin, wait)->
delay wait
>>|. writeD pin st
>>|. blink (Not st, pin, wait))
\end{lstClean}
% VimTeX: SynIgnore off
-\section{Reading guide}
+\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.
repositories / phd-thesis.git / blobdiff