\chapter{Edge device programming}%
\label{chp:top4iot}
-\todo{betere chapter naam}
\begin{chapterabstract}
- This chapter introduces \gls{MTASK} and puts it into perspective compared to traditional microcontroller programming.
- It does so by showing how to program microcontrollers using \gls{ARDUINO}, a popular microcontroller framework, and the equivalent \gls{MTASK} programs.
+ This chapter:
+ \begin{itemize}
+ \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 a short history of \gls{MTASK}'s development.
+ \end{itemize}
\end{chapterabstract}
-The edge layer of \gls{IOT} system mostly consists of microcontrollers that require a different method of programming.
+The edge layer of \gls{IOT} system mostly 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.
+
+\begin{table}
+ \begin{tabular}{llll}
+ \toprule
+ & Laptop & Atmega328P & ESP8266\\
+ \midrule
+ 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}\\
+ Power & \qtyrange{50}{100}{\watt} & \qtyrange{0.13}{250}{\milli\watt} & \qtyrange{0.1}{350}{\milli\watt}\\
+ \bottomrule
+ \end{tabular}
+ \caption{Hardware characteristics of typical microcontrollers and laptops.}%
+ \label{tbl:mcu_laptop}
+\end{table}
+
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.
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.
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 an \gls{LED}.
+Nevertheless, almost always there is a built-in monochrome $1\times1$ pixel screen, namely \pgls{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.
Similar to peripherals (see \cref{sssec:peripherals}), they are constructed at the top level and are accessed through interaction tasks.
The \cleaninline{getSds} task yields the current value of the \gls{SDS} as an unstable value.
This behaviour is similar to the \cleaninline{watch} task in \gls{ITASK}.
-Writing a new value to an \gls{SDS} is done using \cleaninline{setSds}.
+Writing a new value to \pgls{SDS} is done using \cleaninline{setSds}.
This task yields the written value as a stable result after it is done writing.
-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.
+Getting and immediately after setting \pgls{SDS} is not necessarily an \emph{atomic} operation in \gls{MTASK} because it is possible that another task accesses the \gls{SDS} in between.
To circumvent this issue, \cleaninline{updSds} is created, this task atomically updates the value of the \gls{SDS}.
The \cleaninline{updSds} task only guarantees atomicity within \gls{MTASK}.
repositories / phd-thesis.git / blobdiff