conclusion.tex

   1 \section{Conclusion}
   2 This thesis introduces a new view for the existing \gls{mTask}-\gls{EDSL}.
   3 The new view for the \gls{EDSL} compiles the language in to bytecode that can
   4 be interpreted by an \gls{mTask}-client. Clients have been written for several
   5 microcontrollers and consumer architectures that can be connected through
   6 various means of communication such as serial, bluetooth, wifi and wired
   7 network communication. The bytecode on the devices is interpreted using a
   8 simple stack machine and provides the programmer interfaces to the peripherals.
   9 The semantics of the \glspl{mTask} tries to resemble the \gls{iTasks} semantics
  10 as close as possible.
  11
  12 The host language has a very efficient compiler and code generator. Therefore,
  13 the \gls{mTask}-system is also relatively fast because the compilation of
  14 \glspl{mTask} is nothing more than running some functions in the host language.
  15
  16 The dynamic nature allows the microcontroller to be programmed once and used
  17 many times. The program memory of microcontrollers often guarantees around
  18 $10.000$ write or upload cycles and therefore existing techniques such as
  19 generating \gls{C} code are not usable for dynamic \gls{Task} environments.
  20 The dynamic nature also allows the programmer to design fail-over mechanisms.
  21 When a device is assigned a \gls{Task} but another device suddenly becomes
  22 unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
  23 the first device that possibly takes over some of the functionality of the
  24 broken device without needing to recompile the code.
  25
  26 \section{Discussion}
  27
  28 \section{Future Research}
  29 Future improvements of the system could be:
  30 \begin{itemize}
  31         \item Add an additional simulation view to the \gls{mTask}-\gls{EDSL} that
  32                 simulates the bytecode interpreter and possibly functions as a full
  33                 fledged device, thus handling all communication through the existing
  34                 system.
  35         \item Add true multitasking to the client software allowing
  36                 \gls{mTask}-\glspl{Task} to run truly parallel. This does require
  37                 separate stacks for each task and therefore increases the system
  38                 requirements of the client software. However, it could be implemented
  39                 as a compile-time option and exchanged during the handshake so that the
  40                 server knows the multithreading capabilities of the client.
  41         \item Resource analysis during compilation can be useful to determine if an
  42                 \gls{mTask}-\gls{Task} is suitable for a specific device. If the device
  43                 does not contain the correct peripherals such as an \gls{LCD} then the
  44                 \gls{mTask}-\gls{Task} should be rejected and feedback to the user must
  45                 be given. This could also be extended to minimum stack size needed to
  46                 run the task and memory requirements for storing the \gls{Task}.
  47         \item Implement more \gls{Task} combinators such as the step combinator to
  48                 allow for more fine-grained control flow between
  49                 \gls{mTask}-\glspl{Task}. This could be extended to a similar system
  50                 as in the \gls{C}-code generation view. The \glspl{Task} can launch
  51                 other \glspl{Task} and compose \glspl{Task} of subtasks.
  52         \item Implement other classes from the \gls{mTask}-\gls{EDSL} such as the
  53                 \CI{mtask} class that allows tasks launching new tasks.
  54 \end{itemize}