\input{subfilepreamble}
\begin{document}
-\ifSubfilesClassLoaded{
- \pagenumbering{arabic}
-}{}
+\input{subfileprefix}
\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 the 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}
+ \caption{Hardware characteristics of typical microcontrollers and laptops.}%
+ \label{tbl:mcu_laptop}
+ \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}\\
+ Price & \euro{1500} & \euro{3} & \euro{4}\\
+ \bottomrule
+ \end{tabular}
+\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.
\chapter{The \texorpdfstring{\gls{MTASK}}{mTask} \texorpdfstring{\glsxtrshort{DSL}}{DSL}}%
\label{chp:mtask_dsl}
\begin{chapterabstract}
-This chapter serves as a complete guide to the \gls{MTASK} language, from an \gls{MTASK} programmer's perspective.
+This chapter introduces the \gls{MTASK} language more technically by:
+ \begin{itemize}
+ \item introducing the setup of the \gls{EDSL};
+ \item and showing the language interface and examples for:
+ \begin{itemize}
+ \item data types
+ \item expression
+ \item task and their combinators.
+ \end{itemize}
+ \end{itemize}
\end{chapterabstract}
The \gls{MTASK} system is a complete \gls{TOP} programming environment for programming microcontrollers.
\section{Types}
To leverage the type checker of the host language, types in the \gls{MTASK} language are expressed as types in the host language, to make the language type safe.
However, not all types in the host language are suitable for microcontrollers that may only have \qty{2}{\kibi\byte} of \gls{RAM} so class constraints are therefore added to the \gls{DSL} functions.
-The most used class constraint is the \cleaninline{type} class collection containing functions for serialization, printing, \gls{ITASK} constraints \etc.
+The most used class constraint is the \cleaninline{type} class collection containing functions for serialization, printing, \gls{ITASK} constraints, \etc.
Many of these functions can be derived using generic programming.
An even stronger restriction on types is defined for types that have a stack representation.
This \cleaninline{basicType} class has instances for many \gls{CLEAN} basic types such as \cleaninline{Int}, \cleaninline{Real} and \cleaninline{Bool}.
\begin{table}[ht]
\centering
+ \caption{Mapping from \gls{CLEAN}/\gls{MTASK} data types to \gls{CPP} datatypes.}%
+ \label{tbl:mtask-c-datatypes}
\begin{tabular}{lll}
\toprule
\gls{CLEAN}/\gls{MTASK} & \gls{CPP} type & \textnumero{}bits\\
\cleaninline{:: T = A \| B \| C} & \cinline{enum} & 16\\
\bottomrule
\end{tabular}
- \caption{Mapping from \gls{CLEAN}/\gls{MTASK} data types to \gls{CPP} datatypes.}%
- \label{tbl:mtask-c-datatypes}
\end{table}
\Cref{lst:constraints} contains the definitions for the auxiliary types and type constraints (such as \cleaninline{type} an \cleaninline{basicType}) that are used to construct \gls{MTASK} expressions.
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}.
\chapter{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}%
\label{chp:integration_with_itask}
\begin{chapterabstract}
- This chapter shows the integration with \gls{ITASK}.
- It gives an intuition for the architecture of the \gls{IOT} systems.
- The interface for connecting devices, lifting \gls{MTASK} tasks to \gls{ITASK} tasks and lifting \gls{ITASK} \glspl{SDS} to \gls{MTASK} \glspl{SDS} is shown.
+ This chapter shows the integration of \gls{MTASK} with \gls{ITASK} by showing:
+ \begin{itemize}
+ \item an architectural overview of \gls{MTASK};
+ \item on the interface for connecting devices;
+ \item the interface for lifting \gls{MTASK} tasks to \gls{ITASK} tasks;
+ \item and interface for lifting \gls{ITASK} \glspl{SDS} to \gls{MTASK} \glspl{SDS}.
+ \end{itemize}
\end{chapterabstract}
The \gls{MTASK} language is a multi-view \gls{DSL}, i.e.\ there are multiple interpretations possible for a single \gls{MTASK} term.
:: MTDevice //abstract
:: Channels :== ([MTMessageFro], [MTMessageTo], Bool)
-class channelSync a :: a (sds () Channels Channels) -> Task () | RWShared sds
+class channelSync a :: a (Shared sds Channels) -> Task () | RWShared sds
withDevice :: (a (MTDevice -> Task b) -> Task b) | iTask b & channelSync, iTask a
\end{lstClean}
\section{Lifting \texorpdfstring{\glsxtrlongpl{SDS}}{shared data sources}}\label{sec:liftsds}
\begin{lstClean}[label={lst:mtask_itasksds},caption={Lifted \gls{ITASK} \glspl{SDS} in \gls{MTASK}.}]
class liftsds v where
- liftsds :: ((v (Sds t))->In (Shared sds t) (Main (MTask v u)))
+ liftsds :: ((v (Sds t)) -> In (Shared sds t) (Main (MTask v u)))
-> Main (MTask v u) | RWShared sds
\end{lstClean}
\section{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}
IFL18 paper stukken
-\chapter{Green computing with \texorpdfstring{\gls{MTASK}}{mTask}}%
-\label{chp:green_computing_mtask}
-\begin{chapterabstract}
- This chapter demonstrate the energy saving features of \gls{MTASK}.
- First it gives an overview of general green computing measures for edge devices.
- Then \gls{MTASK}'s task scheduling is explained and it is shown how to customise it so suit the applications and energy needs.
- Finally it shows how to use interrupts in \gls{MTASK} to reduce the need for polling.
-\end{chapterabstract}
-
-\section{Green \texorpdfstring{\glsxtrshort{IOT}}{IoT} computing}
-
-\section{Task scheduling}
-\subsection{Language}
-\subsection{Device}
-
-\section{Interrupts}
+\subfile{green}
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / blobdiff