--- /dev/null
+VerbEnvir { lstlisting }
righttextheader={Supervisors:},
righttext={P.W.M. Koopman\\M.J. Plasmeijers}]
+\listoftodos[Todo]
+\tableofcontents
+
\section{Introduction}
\input{intro.tex}
\section{mTasks}
-The current implementation of \emph{mTask}s can be used to generate \emph{C}
-code that will run a mini-taskserver on a microcontroller. This project will
-strip the original \emph{mTask} of this functionality and embed communication
-in the system.
+\input{mtasks.tex}
-\section{Microcontroller}
-Every microcontroller will run the \emph{mTask-engine}. This engine is a
-program that has two jobs. The first job of the engine is to listen to the
-\iTasks{} server to which it is connected via one of the aforementioned
-methods. The \iTasks{} server can send task specifications and SDS
-specifications to the engine to process. Moreover the \iTasks{} server can send
-requests for termination of tasks.
+\section{Architecture}
+\subsection{Microcontroller}
+\input{microcontroller.tex}
-The second job of the engine is to run the tasks in a round robin fashion.
-Every task has a frequency of execution and when the task want a turn he will
-be executed by the engine through interpreting the bytecode. Tasks can change
-SDS's and therefore the engine also has to keep the \iTasks{} server updated
-with the changes. The specifics of this are explained in detail later on.
+\subsection{Bytecode specification}
+\todo{Bytecode specificatie}
-\section{Communication}
+\subsection{Communication}
We can divide the communication up into two parts. Communication from the
\iTasks{} server to the microcontroller and vice versa. The means of
communicating are unimportant, this can be TCP, Serial or any other
communication method that sends data in a linear way.
-\subsection{\iTasks{} $\rightarrow$ microcontroller}
-The \iTasks{} server can send two types of messages. The first and most
-important type is sending a new task to the server. Tasks are dynamically sent
-to the microcontroller, this means that the engine in itself does not do
-anything without it getting a task first from the server. When a task is sent
-the microcontroller acknowledges the message by sending the associated task
-identification number back to the for the server to use in the future.
-The second task is sending SDS specifications to the engine to tell the engine
-what type of SDS will be used in the tasks so that it can be allocated. The
-message structure for sending a task is shown in Table~\ref{tbl:tasksend} and
-the message of sending an SDS specification is shown in
-Table~\ref{tbl:sdsspec}.
-\begin{table}[h]
- \centering
- \begin{tabular}{ll}
- \toprule
- Bytes & Description\\
- \midrule
- \multicolumn{2}{c}{\textbf{Request}}\\
- $1$ & Task send code \verb#'t'#\\
- $2-3$ & Frequency in number of milliseconds as a 16-bit integer\\
- $4-5$ & Length of the bytecode 16-bit integer\\
- $n$ & Bytecode for the task\\
- \midrule
- \multicolumn{2}{c}{\textbf{Response}}\\
- $1$ & Task numeric identification\\
- \bottomrule
- \end{tabular}
- \caption{Message format for sending a task}\label{tbl:tasksend}
-\end{table}
-
-\begin{table}[h]
- \centering
- \begin{tabular}{ll}
- \toprule
- Bytes & Description\\
- \midrule
- \multicolumn{2}{c}{\textbf{Request}}\\
- $1$ & SDS send code \verb#'s'#\\
- $2-3$ & SDS length as a 16-bit integer\\
- $n$ & Value of the SDS identifier\\
- \midrule
- \multicolumn{2}{c}{\textbf{Response}}\\
- $1$ & SDS numeric identification\\
- \bottomrule
- \end{tabular}
- \caption{Message format for sending an SDS specification}\label{tbl:sdssend}
-\end{table}
-
-\subsection{Microcontroller $\rightarrow$ \iTasks{}}
-The only thing the microcontroller has to communicate back with the server is
-an update of the SDS and a request for an SDS value.
-Since all SDSs have a numeric identifier the engine can just send a request
-message with the identifier to the server. A detailed description of the
-message for sending and receiving SDSs is described in
-Tables~\ref{tbl:sdssend},~\ref{tbl:sdsrecv}.
+\subsubsection{\iTasks{} $\rightarrow$ microcontroller}
+\input{commim.tex}
-As said before, publication of SDS values is not done automatically to save
-bandwidth. Therefore the tasks need to have a way of requesting the latest SDS
-value and a way of publishing an updated value. This is elaborated more upon in
-the next section.
+\subsubsection{Microcontroller $\rightarrow$ \iTasks{}}
+\input{commmi.tex}
-\begin{table}[h]
- \centering
- \begin{tabular}{ll}
- \toprule
- Bytes & Description\\
- \midrule
- $1$ & SDS send code \verb#'s'#\\
- $2-3$ & SDS identifier as a 16-bit integer\\
- $4-5$ & Length of the message 16-bit integer\\
- $n$ & Value of the SDS identifier\\
- \bottomrule
- \end{tabular}
- \caption{Message format for a SDS-send operation}\label{tbl:sdssend}
-\end{table}
+\subsection{\iTasks{} task}
+\input{itasks.tex}
-\begin{table}[h]
- \centering
- \begin{tabular}{ll}
- \toprule
- Bytes & Description\\
- \midrule
- \multicolumn{2}{c}{\textbf{Request}}\\
- $1$ & SDS send code \verb#'r'#\\
- $2-3$ & SDS identifier as a 16-bit integer\\
- \midrule
- \multicolumn{2}{c}{\textbf{Response}}\\
- $1-2$ & Length of the message as a 16-bit integer\\
- $n$ & Value of the SDS\\
- \bottomrule
- \end{tabular}
- \caption{Message format for a SDS-receive operation}\label{tbl:sdsrecv}
-\end{table}
+\section{Conclusion}
+\input{conclusion.tex}
\section{Improvements and future research}
In the current implementation the number of possible tasks that can run
and pause one to let another run and through this it will be possible to add
loops to the DSL and make the DSL even more imperative like.
+\todo{Iets over task return values}
+
+\todo{Iets over task combinators}
+
\bibliographystyle{ieeetr}
\bibliography{a}
\end{document}
--- /dev/null
+\usepackage{listings}
+
+\lstdefinelanguage{Clean}{%
+ alsoletter={ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_`1234567890},
+ alsoletter={~!@\#$\%^\&*-+=?<>:|\\.},
+ morekeywords={generic,implementation,definition,dynamic,module,import,from,where,in,of,case,let,infix,infixr,infixl,class,instance,with,if,derive,Void},
+ sensitive=true,
+ morecomment=[l]{//},
+ morecomment=[n]{/*}{*/},
+ morestring=[b]",
+ morestring=[b]',
+ emptylines=1,
+ basicstyle=\small,
+ identifierstyle=\small\ttfamily,
+ commentstyle=\itshape,
+ keywordstyle=\bfseries,
+ stringstyle=\ttfamily,
+ numbers=none,
+ showstringspaces=false,
+ basewidth=0.45em,
+ columns=[c]fixed,
+ keepspaces=true,
+ breaklines=false,
+ tabsize=4,
+ texcl=true,
+ escapeinside={(\#}{\#)},
+ literate=%
+ % Basic Clean constructs
+ {\\}{{$\lambda\:$}}1
+ {A.}{{$\forall\;\,$}}1
+ {E.}{{$\exists\;\,$}}1
+ {>}{{$>$}}1
+ {<}{{$<$}}1
+ {<=}{{$\leq$}}1
+ {>=}{{$\geq$}}1
+ {<>}{{$\neq$}}1
+ {->}{{$\rightarrow$}}2
+ {<-}{{$\leftarrow$}}1
+ {=}{{$=$}}1
+ {~}{{$\sim$}}1
+ {\#}{{$\sharp$}}1
+ {\{|}{{$\{\!|\!$}}1
+ {|\}}{{$\!|\!\}$}}1
+ {:=}{{$:=$}}2
+ {==}{{$==$}}2
+ {++}{{$+\!\!+$}}2
+ {+++}{{$+\!\!\!\!+\!\!\!\!+$}}2
+ {:==}{{$:==$}}3
+ {\{|*|\}}{{$\{\!|\!\!\star\!\!|\!\}$}}3
+ %
+ % Basic iTask constructs
+ {>||>}{{$\triangleright\triangleright$}}2
+ {>>=}{{\texttt{>>=}}}3
+ {>>|}{{\texttt{>>|}}}3
+ {?>>}{{\texttt{?>>}}}3
+ {!>>}{{\texttt{!>>}}}3
+ {-||-}{{\texttt{-||-}}}4
+ {.||.}{{\texttt{.||.}}}4
+ {.&&.}{{\texttt{.\&\&.}}}4
+}
+
+\newcommand{\CleanInline}[1]{\lstinline[language=Clean]¦#1¦}
+\newcommand{\CI}[1]{\CleanInline{#1}}
+
+\lstdefinestyle{numbers}{numbers=left, stepnumber=1, numberstyle=\tiny, numbersep=5pt}
+
+\lstnewenvironment{CleanCode}{\lstset{language=Clean,identifierstyle=\ttfamily}}{}
+\lstnewenvironment{CleanCodeN}{\lstset{language=Clean,style=numbers}}{}
+\lstnewenvironment{CleanCodeB}{\lstset{language=Clean,frame=single}}{}
+\lstnewenvironment{CleanCodeNB}{\lstset{language=Clean,style=numbers,frame=single}}{}
--- /dev/null
+The \iTasks{} server can send two types of messages. The first and most
+important type is sending a new task to the server. Tasks are dynamically sent
+to the microcontroller, this means that the engine in itself does not do
+anything without it getting a task first from the server. When a task is sent
+the microcontroller acknowledges the message by sending the associated task
+identification number back to the for the server to use in the future.
+The second task is sending SDS specifications to the engine to tell the engine
+what type of SDS will be used in the tasks so that it can be allocated. The
+message structure for sending a task is shown in Table~\ref{tbl:tasksend} and
+the message of sending an SDS specification is shown in
+Table~\ref{tbl:sdsspec}.
+\begin{table}[ht]
+ \centering
+ \begin{tabular}{ll}
+ \toprule
+ Bytes & Description\\
+ \midrule
+ \multicolumn{2}{c}{\textbf{Request}}\\
+ $1$ & Task send code \verb#'t'#\\
+ $2-3$ & Frequency in number of milliseconds as a 16-bit integer\\
+ $4-5$ & Length of the bytecode 16-bit integer\\
+ $n$ & Bytecode for the task\\
+ \midrule
+ \multicolumn{2}{c}{\textbf{Response}}\\
+ $1$ & Task numeric identification\\
+ \bottomrule
+ \end{tabular}
+ \caption{Message format for sending a task}\label{tbl:tasksend}
+\end{table}
+
+\begin{table}[ht]
+ \centering
+ \begin{tabular}{ll}
+ \toprule
+ Bytes & Description\\
+ \midrule
+ \multicolumn{2}{c}{\textbf{Request}}\\
+ $1$ & SDS send code \verb#'s'#\\
+ $2-3$ & SDS length as a 16-bit integer\\
+ $n$ & Value of the SDS identifier\\
+ \midrule
+ \multicolumn{2}{c}{\textbf{Response}}\\
+ $1$ & SDS numeric identification\\
+ \bottomrule
+ \end{tabular}
+ \caption{Message format for sending an SDS specification}\label{tbl:sdsspec}
+\end{table}
--- /dev/null
+The only thing the microcontroller has to communicate back with the server is
+an update of the SDS and a request for an SDS value.
+Since all SDSs have a numeric identifier the engine can just send a request
+message with the identifier to the server. A detailed description of the
+message for sending and receiving SDSs is described in
+Tables~\ref{tbl:sdssend},~\ref{tbl:sdsrecv}.
+
+As said before, publication of SDS values is not done automatically to save
+bandwidth. Therefore the tasks need to have a way of requesting the latest SDS
+value and a way of publishing an updated value. This is elaborated more upon in
+the next section.\todo{Type safety of SDS access}
+
+\begin{table}[ht]
+ \centering
+ \begin{tabular}{ll}
+ \toprule
+ Bytes & Description\\
+ \midrule
+ $1$ & SDS send code \verb#'s'#\\
+ $2-3$ & SDS identifier as a 16-bit integer\\
+ $4-5$ & Length of the message 16-bit integer\\
+ $n$ & Value of the SDS identifier\\
+ \bottomrule
+ \end{tabular}
+ \caption{Message format for a SDS-send operation}\label{tbl:sdssend}
+\end{table}
+
+\begin{table}[ht]
+ \centering
+ \begin{tabular}{ll}
+ \toprule
+ Bytes & Description\\
+ \midrule
+ \multicolumn{2}{c}{\textbf{Request}}\\
+ $1$ & SDS send code \verb#'r'#\\
+ $2-3$ & SDS identifier as a 16-bit integer\\
+ \midrule
+ \multicolumn{2}{c}{\textbf{Response}}\\
+ $1-2$ & Length of the message as a 16-bit integer\\
+ $n$ & Value of the SDS\\
+ \bottomrule
+ \end{tabular}
+ \caption{Message format for a SDS-receive operation}\label{tbl:sdsrecv}
+\end{table}
--- /dev/null
+\todo{Conclusie}
-In \emph{Task Oriented Programming} (TOP) a program is built out of pieces of
-work called \emph{tasks}~\cite{achten_introduction_2015}. Tasks differ from
-function in the way that they return a result. A task's return value can change
-over time. Task exist in many forms and they can be composed sequentially and
-in parallel. Some possible tasks are asking for user input via a web browser,
-setting up a TCP connection to another server or combining several tasks. At
-the moment there are several types of leaf tasks. A leaf task is a task that
-does not consist of tasks itself. Examples of leaf tasks are the so called
-editors.
+In \emph{Task Oriented Programming} (TOP) a program is constructed out of
+pieces of work called \emph{tasks}~\cite{achten_introduction_2015}. Tasks
+differ from function in the way that they return a result. A task's return
+value can change over time. Task exist in many forms and they can be composed
+sequentially and in parallel. Some possible tasks are asking for user input via
+a web browser, setting up a TCP connection to another server or combining
+several tasks. At the moment there are several types of leaf tasks. A leaf task
+is a task that does not consist of tasks itself. Examples of leaf tasks are
+the so called editors.
This paper describes the effort to add another type of leaf task that
focusses on microcontrollers. Microcontrollers are often not powerful
abstract away from communication techniques and it should be relatively easy to
add techniques. Techniques that are interesting to experiment with is Serial
communication, Bluetooth, \textsc{WiFi}, \textsc{GSM} and \textsc{LoRa}.
+
+\mTask{}s describe a task in an imperative way and allow the functionality of
+the embedded device to be attached to an \iTasks{} system.
--- /dev/null
+To make the integration of \mTask{}s in \iTasks{} more orthogonal we need a
+special kind of task that serves as a mothertask
--- /dev/null
+Every microcontroller will run the \emph{mTask-engine}. This engine is a
+program that has two jobs. The first job of the engine is to listen to the
+\iTasks{} server to which it is connected via one of the aforementioned
+methods. The \iTasks{} server can send task specifications and SDS
+specifications to the engine to process. Moreover the \iTasks{} server can send
+requests for termination of tasks.
+
+The second job of the engine is to run the tasks in a round robin fashion.
+Every task has a frequency of execution and when the task want a turn he will
+be executed by the engine through interpreting the bytecode. Tasks can change
+SDS's and therefore the engine also has to keep the \iTasks{} server updated
+with the changes. The specifics of this are explained in detail later on.
--- /dev/null
+\emph{mTask}s are written in a shallowly embedded class-based DSL that due to
+the nature of it can be easily extended in language and in view. Currently
+there is a view for generating \emph{C}-code and a view for simulating
+\emph{mTasks} using \iTasks{}. Currently the \emph{mTask} code includes
+functionality for running a small task server on the embedded device. These
+features will not be used in this project as the microcontroller will serve a
+slightly different purpose, namely serve as a task executioner instead of a
+server. The bytecode compilation also adds a class that represents all things
+compilable in bytecode to make sure all the basic types can be compiled. Both
+signatures are shown in Listing~\ref{lst:bytecode}.
+
+In the future a state will probably need to be added to the \CI{Bytecode}
+type to keep track of some information during bytecode compilation.
+
+\begin{lstlisting}[language=Clean,label={lst:bytecode}]
+ :: ByteCode a p = BC [BC]
+ class toByteCode a :: a -> [Char]
+\end{lstlisting}
\usepackage{geometry}
\usepackage{rutitlepage}
\usepackage{booktabs}
+\usepackage{clean}
+\usepackage{xargs}
+\usepackage{todonotes}
\newcommand{\iTasks}{\emph{iTasks}}
+\newcommand{\mTask}{\emph{mTask}}
\author{Mart Lubbers\\\small{s4109503}}
\date{\today}
repositories / ri1617.git / commitdiff