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
  27 \section{Discussion}
  28
  29 \section{Future Research}
  30 Future improvements of the system could be:
  31 \begin{itemize}
  32         \item Add an additional simulation view to the \gls{mTask}-\gls{EDSL} that
  33                 simulates the bytecode interpreter and possibly functions as a full
  34                 fledged device, thus handling all communication through the existing
  35                 system.
  36         \item Add true multitasking to the client software allowing
  37                 \gls{mTask}-\glspl{Task} to run truly parallel. This does require
  38                 separate stacks for each task and therefore increases the system
  39                 requirements of the client software. However, it could be implemented
  40                 as a compile-time option and exchanged during the handshake so that the
  41                 server knows the multithreading capabilities of the client.
  42         \item Resource analysis during compilation can be useful to determine if an
  43                 \gls{mTask}-\gls{Task} is suitable for a specific device. If the device
  44                 does not contain the correct peripherals such as an \gls{LCD} then the
  45                 \gls{mTask}-\gls{Task} should be rejected and feedback to the user must
  46                 be given. This could also be extended to minimum stack size needed to
  47                 run the task and memory requirements for storing the \gls{Task}.
  48         \item Implement more \gls{Task} combinators such as the step combinator to
  49                 allow for more fine-grained control flow between
  50                 \gls{mTask}-\glspl{Task}. This could be extended to a similar system
  51                 as in the \gls{C}-code generation view. The \glspl{Task} can launch
  52                 other \glspl{Task} and compose \glspl{Task} of subtasks.
  53 \end{itemize}