-The \gls{mTask}-\gls{EDSL} is the language used for the proposed system. The
-\gls{mTask}-\gls{EDSL} was created by Koopman et al.\ and supports several
+The \gls{mTask}-\gls{EDSL} was created by Koopman et al.\ and supports several
views such as an \gls{iTasks} simulation and a \gls{C}-code generator. The
\gls{EDSL} was designed to generate a ready-to-compile \gls{TOP}-like program
for microcontrollers such as the \gls{Arduino}~\cite{koopman_type-safe_nodate}%
Not all \glspl{Task} are suitable to run on an \gls{IoT}-device and therefore
-an \gls{EDSL} is used to offer a constrained language to express \glspl{Task}
-for the new system in. The \gls{mTask}-\gls{EDSL} shown in
-Chapter~\ref{chp:mtask} provides a language to create imperative programs that
+an \gls{EDSL} is used to offer a constrained language that expresses \glspl{Task}
+for the new system. The \gls{mTask}-\gls{EDSL} shown in
+Chapter~\ref{chp:mtask} provides the language to create imperative programs that
are suitable to run on microcontrollers. The \gls{EDSL}'s main view is a
-\gls{C} code generator who's code compiles for \gls{Arduino} compatible
+\gls{C} code generator who's code compiles to \gls{Arduino} compatible
microcontrollers. The big downside of this approach is the stiffness of the
system. Once the code has been generated and the microcontroller has been
programmed, nothing can be changed to it anymore. \gls{IoT}-devices often have
To solve this problem, a new view is proposed for the \gls{mTask}-\gls{EDSL}
which compiles the expressions not to \gls{C}-code, but to a bytecode format.
To achieve this, several classes have been added to the \gls{mTask}-\gls{EDSL}.
-Some functionality of the \gls{mTask} system is not used.
+Not all of the functionality of the \gls{mTask} language is used.
The added functionality and implementation to the \gls{mTask}-\gls{EDSL} is
shown in Chapter~\ref{chp:mtaskcont}.
-The original \gls{C}-backend for the \gls{mTask}-\gls{EDSL} generated a
-self-contained \gls{iTasks} like \gls{TOP} system for a microcontroller. The
-proposed backend for the \gls{mTask}-\gls{EDSL} does not result in a
-self-contained system but only compiles the expressions to bytecode. The device
-and the server communicate using the Leader/Follower principle\footnote{Also
-known as Master/Slave}. Only the server can initiate a connection with a device
-and only the server can produce and send \glspl{Task} to the device. Concepts
-such as \glspl{SDS} are available on the device and are the main use of
-communication between the client and the server.
+The existing \gls{C}-backend for the \gls{mTask}-\gls{EDSL} generates a
+self-contained \gls{iTasks} like \gls{TOP} system for microcontrollers. The
+added view for the \gls{mTask}-\gls{EDSL} does not result in a
+self-contained system but compiles the expressions to bytecode representing a
+single \gls{Task}. The device and the server communicate using the
+Leader/Follower principle\footnote{Also known as Master/Slave}. Only the server
+can initiate a connection with a device and only the server can produce and
+send \glspl{Task} to the device. Concepts such as \glspl{SDS} are available on
+the device and are the main use of communication between the client and the
+server.
Chapter~\ref{chp:arch} elaborates on the considerations and implementation of
the system.
-The proposed system provides a bridge between the gap present in the current
-system. It provides a framework to offer functionality for an \gls{iTasks}
-server to outsource \glspl{Task} to \gls{IoT}-devices without needing to
-recompile the code. The \glspl{Task} targeted at \gls{IoT} devices are compiled
-at runtime to bytecode which is sent to the device for interpretation.
+The system researched and built in this research provides a bridge between the
+gap present in the current system. It provides a framework to offer
+functionality for an \gls{iTasks} server to outsource \glspl{Task} to
+\gls{IoT}-devices without needing to recompile the code. The \glspl{Task}
+targeted at \gls{IoT} devices are compiled at runtime to bytecode which is sent
+to the device for interpretation.
The following terms will be used throughout the following chapters:
\begin{itemize}
\item Device, Client
- These terms denotes the actual device connected to the system. This can
- be a real device such as a microcontroller but it can also just be a
- program on the same machine as the server functioning as a client.
+ These terms are used interchangeably and denote the actual device
+ connected to the system. This can be a real device such as a
+ microcontroller but it can also just be a program on the same machine
+ as the server functioning as a client.
\item Server, \gls{iTasks}-System
This is the actual executable serving the \gls{iTasks} application. The
system contains \glspl{Task} taking care of the communication with the
- clients.
+ clients and infrastructure to manage the clients.
\item System
The system describes the complete ecosystem, containing both the server
\vspace{0.4cm}
\textbf{\Large\@title}\\[0.4cm]
\hrule
- \vspace{6cm}
+ \vspace{7cm}
\begin{minipage}[t]{0.45\textwidth}
\begin{flushleft}\large
\textit{Author:}\\
dr.~P.W.M.~Koopman
\end{flushright}
\end{minipage}
- \vspace{1cm}
\vfill
{\large\@date}
\end{center}
repositories / msc-thesis1617.git / commitdiff