\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. Therefore,
+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}
repositories / msc-thesis1617.git / blobdiff