X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=top%2Ftop.tex;fp=top%2Ftop.tex;h=619789f2ed56522d8c152aa05a1b0e9db4e4c438;hb=b460fb90ed81b62d4b1c219271e29ece38c1ffab;hp=25200c40db04e8c4cffa42341b4f6d2e55889d77;hpb=b20c3c8a47ab555186a270a120f23bed6ca79b38;p=phd-thesis.git

diff --git a/top/top.tex b/top/top.tex
index 25200c4..619789f 100644
--- a/top/top.tex
+++ b/top/top.tex
@@ -1,5 +1,7 @@
 \documentclass[../thesis.tex]{subfiles}
 
+\input{subfilepreamble}
+
 \begin{document}
 \ifSubfilesClassLoaded{
 	\pagenumbering{arabic}
@@ -382,6 +384,7 @@ They lift the value from the \gls{MTASK} expression language to the task domain
 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
@@ -394,7 +397,7 @@ For every sensor or actuator, basic tasks are available that allow interaction w
 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.
@@ -429,7 +432,7 @@ Setting the pin mode is a task that immediately finisheds and fields a stable un
 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
@@ -449,6 +452,14 @@ class pinMode v where
 	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:
@@ -552,7 +563,7 @@ task =
 	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}.
@@ -570,19 +581,19 @@ task :: MTask v Int | mtask v
 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
@@ -593,7 +604,23 @@ class sds v where
 	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}
@@ -642,7 +669,7 @@ Once the connection with the device is established, \ldots
 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)))
@@ -678,7 +705,7 @@ Moreover, a course on the \gls{MTASK} simulator was provided at the 2018 \gls{CE
 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}.