X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=top%2Ftop.tex;h=3f18e5a6e327c3343312779dd0159d2f5d41a908;hb=4af0c6b6072b8a811dabadd2b66df5730dd3be41;hp=619789f2ed56522d8c152aa05a1b0e9db4e4c438;hpb=11bda54fc5a192544e945b73c5455b1ab3275078;p=phd-thesis.git diff --git a/top/top.tex b/top/top.tex index 619789f..3f18e5a 100644 --- a/top/top.tex +++ b/top/top.tex @@ -7,30 +7,38 @@ \pagenumbering{arabic} }{} -\chapter{Introduction to \texorpdfstring{\gls{IOT}}{IoT} programming}% +\chapter{Introduction to \texorpdfstring{\glsxtrshort{IOT}}{IoT} device programming}% \label{chp:top4iot} \todo{betere chapter naam} \begin{chapterabstract} This chapter introduces \gls{MTASK} and puts it into perspective compared to traditional microprocessor programming. \end{chapterabstract} +The edge layer of \gls{IOT} system mostly consists of microprocessors that require a different method of programming. +Usually, programming microprocessors requires an elaborate multi-step toolchain of compilation, linkage, binary image creation, and burning this image onto the flash memory of the microprocessor 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. +Each type of microprocessors 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 microprocessor behaviour allowing the programmer to program multiple types of microprocessors 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. + +\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 microprocessors, there often is no screen for displaying text. -Nevertheless, almost always there is a monochrome $1\times1$ pixel screen, namely an---often builtin---\gls{LED}. +On microprocessors, 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}. The \emph{Hello World!} equivalent on microprocessors blinks this \gls{LED}. -\Cref{lst:arduinoBlink} shows how the logic of a blink program might look when using \gls{ARDUINO}'s \gls{CPP} dialect. +\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. 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 500 milliseconds so that the blinking is actually visible for the human eye. -Compiling this results in a binary firmware that needs to be flashed onto the program memory. +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 can be used, this task executes the argument task and, when stable, reinstates it. +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. @@ -46,7 +54,8 @@ void loop() { delay(500); digitalWrite(D2, LOW); delay(500); -}\end{lstArduino} +} + \end{lstArduino} \end{subfigure}% \begin{subfigure}[b]{.5\linewidth} \begin{lstClean}[caption={Blink program.},label={lst:blinkImp}] @@ -59,13 +68,14 @@ blink = >>|. writeD d2 false >>|. delay (lit 500) ) -}\end{lstClean} +} + \end{lstClean} \end{subfigure} \end{figure} \section{Threaded blinking} 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 $500,300$ and $800$ milliseconds. +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} \begin{lstArduino}[caption={Naive approach to multiple blinking patterns.},label={lst:blinkthreadno}] @@ -86,7 +96,7 @@ void loop() { 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}. +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. Furthermore, the \arduinoinline{delay} function can not be used and polling \arduinoinline{millis} is required. @@ -142,35 +152,76 @@ blinktask = }\end{lstClean} % VimTeX: SynIgnore off -\chapter{The \texorpdfstring{\gls{MTASK}}{mTask} \texorpdfstring{\gls{DSL}}{DSL}}% +\section{\texorpdfstring{\Gls{MTASK}}{MTask} history} +\subsection{Generating \texorpdfstring{\gls{C}/\gls{CPP}}{C/C++} code} +A first throw at a class-based shallowly \gls{EDSL} for microprocessors 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 or even functions. +Some time later in the 2015 \gls{CEFP} summer school, an extended version was created that allowed the creation of imperative tasks, \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}. + +\section{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, tasks and \glspl{SDS} but still compiled to \gls{CPP} \gls{ARDUINO} code. +Later the bytecode 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 microprocessor 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 (the lecture notes are to be written). +Several students worked on extending \gls{MTASK} with many useful features: +\Citet{veen_van_der_mutable_2020} did preliminary work on a green computer analysis, built a simulator and explored the possibilities for adding bounded datatypes; \citet{boer_de_secure_2020} investigated the possibilities for secure communication channels; and \citet{crooijmans_reducing_2021} added abstractions for low-power operation to \gls{MTASK} such as hardware interrupts and power efficient scheduling (resulting in a paper as well \citet{crooijmans_reducing_2022}). +\Citet{antonova_mtask_2022} defined a preliminary formal semantics for a subset of \gls{MTASK}. +Moreover, plans for student projects and improvements include exploring integrating \gls{TINYML} into \gls{MTASK}; and adding intermittent computing support to \gls{MTASK}. + +In 2023, the SusTrainable summer school in Coimbra, Portugal will host a course on \gls{MTASK} as well. + +\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. + +\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. \end{chapterabstract} -The \gls{MTASK} system is a \gls{TOP} programming environment for programming microprocessors. -It is implemented as an\gls{EDSL} in \gls{CLEAN} using class-based---or tagless-final---embedding (See \cref{ssec:tagless}). -Due to the nature of the embedding technique, it is possible to have multiple interpretations of---or views on---programs written in the \gls{MTASK} language. +The \gls{MTASK} system is a complete \gls{TOP} programming environment for programming microprocessors. +It is implemented as an \gls{EDSL} in \gls{CLEAN} using class-based---or tagless-final---embedding (see \cref{sec:tagless-final_embedding}). + +Due to the nature of the embedding technique, it is possible to have multiple views on-programs written in the \gls{MTASK} language. The following interpretations are available for \gls{MTASK}. -\begin{itemize} - \item Pretty printer +\begin{description} + \item[Pretty printer] This interpretation converts the expression to a string representation. - \item Simulator + \item[Simulator] The simulator converts the expression to a ready-for-work \gls{ITASK} simulation in which the user can inspect and control the simulated peripherals and see the internal state of the tasks. - \item Compiler + \item[Byte code compiler] - The compiler compiles the \gls{MTASK} program at runtime to a specialised bytecode. + The compiler compiles the \gls{MTASK} program at runtime to a specialised byte code. Using a handful of integration functions and tasks, \gls{MTASK} tasks can be executed on microprocessors and integrated in \gls{ITASK} as if they were regular \gls{ITASK} tasks. Furthermore, with special language constructs, \glspl{SDS} can be shared between \gls{MTASK} and \gls{ITASK} programs. -\end{itemize} +\end{description} When using the compiler interpretation in conjunction with the \gls{ITASK} integration, \gls{MTASK} is a heterogeneous \gls{DSL}. -I.e.\ some components---e.g.\ the \gls{RTS} on the microprocessor---is largely unaware of the other components in the system. -Furthermore, it is executed on a completely different architecture. -The \gls{MTASK} language consists of a host language---a simply-typed $\lambda$-calculua with support for some basic types, function definition and data types (see \cref{sec:expressions})---enriched with a task language (see \cref{sec:top}). +I.e.\ some components---e.g.\ the \gls{RTS} on the microprocessor---is largely unaware of the other components in the system, and it is executed on a completely different architecture. +The \gls{MTASK} language is an enriched simply-typed $\lambda$-calculus with support for some basic types, arithmetic operations, and function definition; and a task language (see \cref{sec:top}). \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. @@ -199,37 +250,41 @@ The class constraints for values in \gls{MTASK} are omnipresent in all functions \label{tbl:mtask-c-datatypes} \end{table} -The \gls{MTASK} language consists of a core collection of type classes bundled in the type class \cleaninline{class mtask}. +\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. +The \gls{MTASK} language interface consists of a core collection of type classes bundled in the type class \cleaninline{class mtask}. Every interpretation implements the type classes in the \cleaninline{mtask} class -There are also \gls{MTASK} extensions that not every interpretation implements such as peripherals and integration with \gls{ITASK}. - -\Cref{lst:constraints} contains the definitions for the type constraints and shows some example type signatures for typical \gls{MTASK} expressions and tasks. -\todo{uitleggen} - +There are also \gls{MTASK} extensions that not every interpretation implements such as peripherals and \gls{ITASK} integration. \begin{lstClean}[caption={Classes and class collections for the \gls{MTASK} language.},label={lst:constraints}] -:: Main a = { main :: a } -:: In a b = (In) infix 0 a b - class type t | iTask, ... ,fromByteCode, toByteCode t class basicType t | type t where ... class mtask v | expr, ..., int, real, long v -someExpr :: v Int | mtask v -someExpr = ... +\end{lstClean} + +Sensors, \glspl{SDS}, functions, \etc{} may only be defined at the top level. +The \cleaninline{Main} type is used that is used to distinguish the top level from the main expression. +Some top level definitions, such as functions, are defined using \gls{HOAS}. +To make their syntax friendlier, the \cleaninline{In} type---an infix tuple---is used to combine these top level definitions as can be seen in \cleaninline{someTask} (\cref{lst:mtask_types}). -someTask :: MTask v Int | mtask v +\begin{lstClean}[caption={Example task and auxiliary types in the \gls{MTASK} language.},label={lst:mtask_types}] +:: Main a = { main :: a } +:: In a b = (In) infix 0 a b + +someTask :: MTask v Int | mtask v & liftsds v & sensor1 v & ... someTask = sensor1 config1 \sns1-> sensor2 config2 \sns2-> - fun \fun1= ( ... ) + sds \s1=initial + In liftsds \s2=someiTaskSDS + In fun \fun1= ( ... ) In fun \fun2= ( ... ) - In {main=mainexpr} + In { main = mainexpr } \end{lstClean} \section{Expressions}\label{sec:expressions} \Cref{lst:expressions} shows the \cleaninline{expr} class containing the functionality to lift values from the host language to the \gls{MTASK} language (\cleaninline{lit}); perform number and boolean arithmetics; do comparisons; and conditional execution. -For every common arithmetic operator in the host language, an \gls{MTASK} variant is present, suffixed by a period to not clash with \gls{CLEAN}'s builtin operators. +For every common boolean and arithmetic operator in the host language, an \gls{MTASK} variant is present, suffixed by a period to not clash with \gls{CLEAN}'s builtin operators. \begin{lstClean}[caption={The \gls{MTASK} class for expressions},label={lst:expressions}] class expr v where @@ -244,7 +299,7 @@ class expr v where If :: (v Bool) (v t) (v t) -> v t | type t \end{lstClean} -Conversion to-and-fro data types is available through the overloaded functions \cleaninline{int}, \cleaninline{long} and \cleaninline{real}. +Conversion to-and-fro data types is available through the overloaded functions \cleaninline{int}, \cleaninline{long} and \cleaninline{real} that will convert the argument to the respective type similar to casting in \gls{C}. \begin{lstClean}[caption={Type conversion functions in \gls{MTASK}.}] class int v a :: (v a) -> v Int @@ -252,15 +307,13 @@ class real v a :: (v a) -> v Real class long v a :: (v a) -> v Long \end{lstClean} -Finally, values from the host language must be explicitly lifted to the \gls{MTASK} language using the \cleaninline{lit} function. +Values from the host language must be explicitly lifted to the \gls{MTASK} language using the \cleaninline{lit} function. For convenience, there are many lower-cased macro definitions for often used constants such as \cleaninline{true :== lit True}, \cleaninline{false :== lit False}, \etc. \Cref{lst:example_exprs} shows some examples of these expressions. +Since they are only expressions, there is no need for a \cleaninline{Main}. \cleaninline{e0} defines the literal $42$, \cleaninline{e1} calculates the literal $42.0$ using real numbers. \cleaninline{e2} compares \cleaninline{e0} and \cleaninline{e1} as integers and if they are equal it returns the \cleaninline{e2}$/2$ and \cleaninline{e0} otherwise. -\cleaninline{approxEqual} performs an approximate equality---albeit not taking into account all floating point pecularities---and demonstrates that \gls{CLEAN} can be used as a macro language, i.e.\ maximise linguistic reuse~\cite{krishnamurthi_linguistic_2001}. -\todo{uitzoeken waar dit handig is} -When calling \cleaninline{approxEqual} in an \gls{MTASK} function, the resulting code is inlined. \begin{lstClean}[label={lst:example_exprs},caption={Example \gls{MTASK} expressions.}] e0 :: v Int | expr v @@ -272,23 +325,31 @@ e1 = lit 38.0 + real (lit 4) e2 :: v Int | expr v e2 = if' (e0 ==. int e1) (int e1 /. lit 2) e0 +\end{lstClean} + +\Gls{MTASK} is shallowly embedded in \gls{CLEAN} and the terms are constructed at runtime. +This means that \gls{MTASK} programs can also be tailor-made at runtime or constructed using \gls{CLEAN} functions maximising the linguistic reuse \citep{krishnamurthi_linguistic_2001} +\cleaninline{approxEqual} in \cref{lst:example_macro} performs an approximate equality---albeit not taking into account all floating point pecularities---. +When calling \cleaninline{approxEqual} in an \gls{MTASK} function, the resulting code is inlined. +\begin{lstClean}[label={lst:example_macro},caption={Example linguistic reuse in the \gls{MTASK} language.}] approxEqual :: (v Real) (v Real) (v Real) -> v Real | expr v -approxEqual x y eps = if' (x == y) true - ( if' (x > y) +approxEqual x y eps = if' (x ==. y) true + ( if' (x >. y) (y -. x < eps) (x -. y < eps) ) \end{lstClean} -\subsection{Data Types} +\subsection{Data types} Most of \gls{CLEAN}'s basic types have been mapped on \gls{MTASK} types. However, it can be useful to have access to compound types as well. All types in \gls{MTASK} must have a fixed size representation on the stack so sum types are not (yet) supported. While it is possible to lift types using the \cleaninline{lit} function, you cannot do anything with the types besides passing them around but they are being produced by some parallel task combinators (see \cref{sssec:combinators_parallel}). -To be able to use types as first class citizens, constructors and field selectors are required. +To be able to use types as first class citizens, constructors and field selectors are required (see \cref{chp:first-class_datatypes}). \Cref{lst:tuple_exprs} shows the scaffolding for supporting tuples in \gls{MTASK}. Besides the constructors and field selectors, there is also a helper function available that transforms a function from a tuple of \gls{MTASK} expressions to an \gls{MTASK} expression of a tuple. +Examples for using tuple can be found in \cref{sec:mtask_functions}. \begin{lstClean}[label={lst:tuple_exprs},caption={Tuple constructor and field selectors in \gls{MTASK}.}] class tupl v where @@ -299,15 +360,14 @@ class tupl v where tupopen f :== \v->f (first v, second v) \end{lstClean} -\subsection{Functions} -Adding functions to the language is achieved by one multi-parameter class to the \gls{DSL}. -By using \gls{HOAS}, both the function definition and the calls to the function can be controlled by the \gls{DSL}~\citep{pfenning_higher-order_1988,chlipala_parametric_2008}. -As \gls{MTASK} only supports first-order functions and does not allow partial function application. -Using a type class of this form, this restriction can be enforced on the type level. -Instead of providing one instance for all functions, a single instance per function arity is defined. +\subsection{Functions}\label{sec:mtask_functions} +Adding functions to the language is achieved by type class to the \gls{DSL}. +By using \gls{HOAS}, both the function definition and the calls to the function can be controlled by the \gls{DSL} \citep{pfenning_higher-order_1988,chlipala_parametric_2008}. +The \gls{MTASK} only allows first-order functions and does not allow partial function application. +This is restricted by using a multi-parameter type class where the first parameter represents the arguments and the second parameter the view. +By providing a single instance per function arity instead of providing one instance for all functions and using tuples for the arguments this constraint can be enforced. Also, \gls{MTASK} only supports top-level functions which is enforced by the \cleaninline{Main} box. -The definition of the type class and the instances for an example interpretation are as follows: -\todo{uitbreiden} +The definition of the type class and the instances for an example interpretation (\cleaninline{:: Inter}) are as follows: \begin{lstClean}[caption={Functions in \gls{MTASK}.}] class fun a v :: ((a -> v s) -> In (a -> v s) (Main (MTask v u))) @@ -315,8 +375,8 @@ class fun a v :: ((a -> v s) -> In (a -> v s) (Main (MTask v u))) instance fun () Inter where ... instance fun (Inter a) Inter | type a where ... -instance fun (Inter a, Inter b) Inter | type a where ... -instance fun (Inter a, Inter b, Inter c) Inter | type a where ... +instance fun (Inter a, Inter b) Inter | type a, type b where ... +instance fun (Inter a, Inter b, Inter c) Inter | type a, ... where ... ... \end{lstClean} @@ -358,7 +418,7 @@ swapTuple = \end{lstClean} % VimTeX: SynIgnore off -\section{Tasks}\label{sec:top} +\section{Tasks and task combinators}\label{sec:top} \Gls{MTASK}'s task language can be divided into three categories, namely \begin{enumerate*} \item Basic tasks, in most \gls{TOP} systems, the basic tasks are called editors, modelling the interactivity with the user. @@ -395,7 +455,7 @@ class delay v :: (v n) -> MTask v n | long v n \subsubsection{Peripherals}\label{sssec:peripherals} For every sensor or actuator, basic tasks are available that allow interaction with the specific peripheral. The type classes for these tasks are not included in the \cleaninline{mtask} class collection as not all devices nor all language interpretations have such peripherals connected. -\todo{Historically, peripheral support has been added \emph{by need}.} +%\todo{Historically, peripheral support has been added \emph{by need}.} \Cref{lst:dht,lst:gpio} show the type classes for \glspl{DHT} sensors and \gls{GPIO} access. Other peripherals have similar interfaces, they are available in the \cref{sec:aux_peripherals}. @@ -625,6 +685,14 @@ task = declarePin D3 PMInput \d3-> \chapter{Green computing with \texorpdfstring{\gls{MTASK}}{mTask}}% \label{chp:green_computing_mtask} +\section{Green \texorpdfstring{\glsxtrshort{IOT}}{IoT} computing} + +\section{Task scheduling} +\subsection{Language} +\subsection{Device} + +\section{Interrupts} + \chapter{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}% \label{chp:integration_with_itask} The \gls{MTASK} language is a multi-view \gls{DSL}, i.e.\ there are multiple interpretations possible for a single \gls{MTASK} term. @@ -683,46 +751,5 @@ IFL19 paper, bytecode instructieset~\cref{chp:bytecode_instruction_set} \section{Integration with \texorpdfstring{\gls{ITASK}}{iTask}} IFL18 paper stukken -\chapter{\texorpdfstring{\gls{MTASK}}{mTask} history} -\section{Generating \texorpdfstring{\gls{C}/\gls{CPP}}{C/C++} code} -A first throw at a class-based shallowly \gls{EDSL} for microprocessors 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 or even functions. -Some time later in the 2015 \gls{CEFP} summer school, an extended version was created that allowed the creation of imperative tasks, \glspl{SDS} and the usage of functions~\citep{koopman_type-safe_2019}. -The name then changed from \gls{ARDSL} to \gls{MTASK}. - -\section{Integration with \texorpdfstring{\gls{ITASK}}{iTask}} -Mart Lubbers extended this in his Master's Thesis by adding integration with \gls{ITASK} and a bytecode compiler to the language~\citep{lubbers_task_2017}. -\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 Matheus Amazonas Cabral de Andrade that it was possible to build real-life \gls{IOT} systems with this integration~\citep{amazonas_cabral_de_andrade_developing_2018}. -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}. - -\section{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, tasks and \glspl{SDS} but still compiled to \gls{CPP} \gls{ARDUINO} code. -Later the bytecode 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 microprocessor 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}. - -\section{\texorpdfstring{\gls{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 (the lecture notes are to be written). -Several students worked on extending \gls{MTASK} with many useful features: -Erin van der Veen did preliminary work on a green computer analysis, built a simulator and explored the possibilities for adding bounded datatypes~\citep{veen_van_der_mutable_2020}; Michel de Boer investigated the possibilities for secure communication channels~\citep{boer_de_secure_2020}; and Sjoerd Crooijmans added abstractions for low-power operation to \gls{MTASK} such as hardware interrupts and power efficient scheduling~\citep{crooijmans_reducing_2021}. -Elina Antonova defined a preliminary formal semantics for a subset of \gls{MTASK}~\citep{antonova_MTASK_2022}. -Moreover, plans for student projects and improvements include exploring integrating \gls{TINYML} into \gls{MTASK}; and adding intermittent computing support to \gls{MTASK}. - -In 2023, the SusTrainable summer school in Coimbra, Portugal will host a course on \gls{MTASK} as well. - -\section{\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}. -The collaboration is still ongoing and a journal article is under review comparing four approaches for the edge layer: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK} and \gls{MTASK}. -Furthermore, 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 - \input{subfilepostamble} \end{document}