\section{Conclusion}
This thesis introduces a new view for the existing \gls{mTask}-\gls{EDSL}.
The new view for the \gls{EDSL} compiles the language in to bytecode that can
be interpreted by an \gls{mTask}-client. Clients have been written for several
microcontrollers and consumer architectures that can be connected through
various means of communication such as serial, bluetooth, wifi and wired
network communication. The bytecode on the devices is interpreted using a
simple stack machine and provides the programmer interfaces to the peripherals.
The semantics of the \glspl{mTask} tries to resemble the \gls{iTasks} semantics
as close as possible.

The host language has a very efficient compiler and code generator the
\gls{mTask}-system is also relatively fast because the compilation of
\glspl{mTask} is nothing more than running some functions in the host language.

The dynamic nature allows the microcontroller to be programmed once and used
many times. The program memory of microcontrollers often guarantees around
$10.000$ write or upload cycles and therefore existing techniques such as
generating \gls{C} code are not usable for dynamic \gls{Task} environments.
The dynamic nature also allows the programmer to design fail-over mechanisms.
When a device is assigned a \gls{Task} but another device suddenly becomes
unusable the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
the first device that possibly takes over some of the functionality of the
broken device without needing to recompile the code.


\section{Discussion}

\section{Future Research}
Future improvements of the system could be:
\begin{itemize}
	\item Add an additional simulation view to the \gls{mTask}-\gls{EDSL} that
		simulates the bytecode interpreter and possibly functions as a full
		fledged device, thus handling all communication through the existing
		system.
	\item Add true multitasking to the client software allowing
		\gls{mTask}-\glspl{Task} to run truly parallel. This does require
		separate stacks for each task and therefore increases the system
		requirements of the client software. However, it could be implemented
		as a compile-time option and exchanged during the handshake so that the
		server knows the multithreading capabilities of the client.
	\item Resource analysis during compilation can be useful to determine if an
		\gls{mTask}-\gls{Task} is suitable for a specific device. If the device
		does not contain the correct peripherals such as an \gls{LCD} then the
		\gls{mTask}-\gls{Task} should be rejected and feedback to the user must
		be given. This could also be extended to minimum stack size needed to
		run the task and memory requirements for storing the \gls{Task}.
	\item Implement more \gls{Task} combinators such as the step combinator to
		allow for more fine-grained control flow between
		\gls{mTask}-\glspl{Task}. This could be extended to a similar system
		as in the \gls{C}-code generation view. The \glspl{Task} can launch
		other \glspl{Task} and compose \glspl{Task} of subtasks.
\end{itemize}
