righttext={P.W.M. Koopman\\M.J. Plasmeijers}]
\section{Introduction}
-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.
-
-This paper describes the effort to add another type of leaf task that
-focusses on microcontrollers. Microcontrollers are often not powerful
-enough to run a full-fledged task server and therefore there is the need to
-introduce special microcontroller tasks. Effort for this is already made by by
-the department~\cite{koopman_tasks_2016}. However, communication between the
-\emph{mTask} and the iTasks system is still lacking and exactly that will be the
-goal of the project. This requires adding a new type of leaf task that allows
-the user to run \emph{mTasks} on microcontrollers. The leaf task should
-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}.
+\input{intro.tex}
\section{mTasks}
The current implementation of \emph{mTask}s can be used to generate \emph{C}
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.
+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
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 SDS's have a numeric identifier the engine can just send a request
+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 is described in Table~\ref{tbl:sdssend}.
+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.
-\begin{table}[H]
+\begin{table}[h]
\centering
\begin{tabular}{ll}
\toprule
Bytes & Description\\
\midrule
$1$ & SDS send code \verb#'s'#\\
- $2-5$ & SDS identifier as a 16-bit integer\\
- $2-5$ & Length of the message 16-bit integer\\
+ $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}[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{Improvements and future research}
In the current implementation the number of possible tasks that can run
simultaneously is fixed. A future project can implement dynamic task allocation
repositories / ri1617.git / blobdiff