\documentclass[../thesis.tex]{subfiles}
+\input{subfilepreamble}
+
\begin{document}
\ifSubfilesClassLoaded{
\pagenumbering{arabic}
There is also a special type of basic task for delaying execution.
The \cleaninline{delay} task---given a number of milliseconds---yields an unstable value while the time has not passed.
Once the specified time has passed, the time it overshot the planned time is yielded as a stable task value.
+See \cref{sec:repeat} for an example task using \cleaninline{delay}.
\begin{lstClean}[label={lst:basic_tasks},caption={Function examples in \gls{MTASK}.}]
class rtrn v :: (v t) -> MTask v t
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}.}
-\Cref{lst:dht} and \cref{lst:gpio} show the type classes for \glspl{DHT} sensors and \gls{GPIO} access.
+\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}.
For the \gls{DHT} sensor there are two basic tasks, \cleaninline{temperature} and \cleaninline{humidity}, that---will given a \cleaninline{DHT} object---produce a task that yields the observed temperature in \unit{\celcius} or relative humidity as a percentage as an unstable value.
Currently, two different types of \gls{DHT} sensors are supported, the \emph{DHT} family of sensors connect through $1$-wire protocol and the \emph{SHT} family of sensors connected using \gls{I2C} protocol.
Writing to a pin is also a task that immediately finishes but yields the written value instead.
Reading a pin is a task that yields an unstable value---i.e.\ the value read from the actual pin.
-\begin{lstClean}[label={lst:gpio},caption{The \gls{MTASK} interface for \gls{GPIO} access.}]
+\begin{lstClean}[label={lst:gpio},caption={The \gls{MTASK} interface for \gls{GPIO} access.}]
:: APin = A0 | A1 | A2 | A3 | A4 | A5
:: DPin = D0 | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13
:: PinMode = PMInput | PMOutput | PMInputPullup
declarePin :: p PinMode ((v p) -> Main (v a)) -> Main (v a) | pin p
\end{lstClean}
+\begin{lstClean}[label={lst:gpio_examples},caption={\Gls{GPIO} example in \gls{MTASK}.}]
+task1 :: MTask v Int | mtask v
+task1 = declarePin A3 PMInput \a3->{main=readA a3}
+
+task2 :: MTask v Int | mtask v
+task2 = declarePin D3 PMOutput \d3->{main=writeD d3 true}
+\end{lstClean}
+
\subsection{Task combinators}
Task combinators are used to combine multiple tasks into one to describe workflows.
There are three main types of task combinators, namely:
In {main = monitor d0 .||. monitor d1}
\end{lstClean}
-\subsubsection{Repeat}
+\subsubsection{Repeat}\label{sec:repeat}
The \cleaninline{rpeat} combinator executes the child task.
If a stable value is observed, the task is reinstated.
The functionality of \cleaninline{rpeat} can also be simulated by using functions and sequential task combinators and even made to be stateful as can be seen in \cref{lst:blinkthreadmtask}.
task =
declarePin A1 PMInput \a1->
declarePin A2 PMOutput \a2->
- {main = rpeat (readA a1 >>~. writeA a2)}
+ {main = rpeat (readA a1 >>~. writeA a2 >>|. delay (lit 1000))}
\end{lstClean}
-\subsection{\texorpdfstring{\Acrlongpl{SDS}}{Shared data sources}}
-\Glspl{SDS} in \gls{MTASK} are by default references to shared memory.
+\subsection{\texorpdfstring{\Glsxtrlongpl{SDS}}{Shared data sources}}
+\Glspl{SDS} in \gls{MTASK} are by default references to shared memory but can also be references to \glspl{SDS} in \gls{ITASK} (see \cref{sec:liftsds}).
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}.
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 an \emph{atomic} operation.
-It is possible that another task accesses the \gls{SDS} in between.
+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.
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}.
\begin{lstClean}[label={lst:mtask_sds},caption={\Glspl{SDS} in \gls{MTASK}.}]
:: Sds a // abstract
updSds :: (v (Sds t)) ((v t) -> v t) -> MTask v t
\end{lstClean}
-\todo{examples sdss}
+\Cref{lst:mtask_sds_examples} shows an example using \glspl{SDS}.
+The \cleaninline{count} function takes a pin and returns a task that counts the number of times the pin is observed as high by incrementing the \cleaninline{share} \gls{SDS}.
+In the \cleaninline{main} expression, this function is called twice and the results are combined using the parallel or combinator (\cleaninline{.||.}).
+Using a sequence of \cleaninline{getSds} and \cleaninline{setSds} would be unsafe here because the other branch might write their old increment value immediately after writing, effectively missing a count.\todo{beter opschrijven}
+
+\begin{lstClean}[label={lst:mtask_sds_examples},caption={Examples with \glspl{SDS} in \gls{MTASK}.}]
+task :: MTask v Int | mtask v
+task = declarePin D3 PMInput \d3->
+ declarePin D5 PMInput \d5->
+ sds \share=0
+ In fun \count=(\pin->
+ readD pin
+ >>* [IfValue (\x->x) (\_->updSds (\x->x +. lit 1) share)]
+ >>| delay (lit 100) // debounce
+ >>| count pin)
+ In {main=count d3 .||. count d5}
+\end{lstClean}
\chapter{Green computing with \texorpdfstring{\gls{MTASK}}{mTask}}%
\label{chp:green_computing_mtask}
liftmTask :: (Main (BCInterpret (TaskValue u))) MTDevice -> Task u | iTask u
\end{lstClean}
-\section{Lifting \texorpdfstring{\acrlongpl{SDS}}{shared data sources}}\label{sec:liftsds}
+\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)))
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 \gls{MCU} applications in a \gls{TOP} language~\citep{lubbers_multitasking_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}.
repositories / phd-thesis.git / blobdiff