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}
repositories / ri1617.git / blobdiff