architecture/a.tex

   1 %&a
   2 \begin{document}
   3 \maketitleru[
   4         course={Research Intership},
   5         righttextheader={Supervisors:},
   6         righttext={P.W.M. Koopman\\M.J. Plasmeijers}]
   7
   8 \listoftodos[Todo]
   9 \tableofcontents
  10
  11 \section{Introduction}
  12 \input{intro.tex}
  13
  14 \section{mTasks}
  15 \input{mtasks.tex}
  16
  17 \section{Architecture}
  18 \subsection{Microcontroller}
  19 \input{microcontroller.tex}
  20
  21 \subsection{Bytecode specification}
  22 \todo{Bytecode specificatie}
  23
  24 \subsection{Communication}
  25 We can divide the communication up into two parts. Communication from the
  26 \iTasks{} server to the microcontroller and vice versa. The means of
  27 communicating are unimportant, this can be TCP, Serial or any other
  28 communication method that sends data in a linear way.
  29
  30 \subsubsection{\iTasks{} $\rightarrow$ microcontroller}
  31 \input{commim.tex}
  32
  33 \subsubsection{Microcontroller $\rightarrow$ \iTasks{}}
  34 \input{commmi.tex}
  35
  36 \subsection{\iTasks{} task}
  37 \input{itasks.tex}
  38
  39 \section{Conclusion}
  40 \input{conclusion.tex}
  41
  42 \section{Improvements and future research}
  43 In the current implementation the number of possible tasks that can run
  44 simultaneously is fixed. A future project can implement dynamic task allocation
  45 and garbage collection that is then needed. Since memory is scarce on a
  46 microcontroller the program can not go and \verb#malloc# all the time to
  47 allocate new memory on the heap for the tasks. Over time this will cause
  48 fragmentation and eventually the program will run out of memory. A solution for
  49 this could be to let the engine handle the memory management and reorder and
  50 defragment the tasks on demand.
  51
  52 Another improvement could be the task scheduling. At the moment all tasks get
  53 one slice in which they are executed as a whole. Because of this the use of
  54 loops is not possible since a loop will block the entire program. A possible
  55 solution for this is to give different stack and program pointers to each task
  56 and save them separately. In this way the interpreter can slice the programs
  57 and pause one to let another run and through this it will be possible to add
  58 loops to the DSL and make the DSL even more imperative like.
  59
  60 \todo{Iets over task return values}
  61
  62 \todo{Iets over task combinators}
  63
  64 \bibliographystyle{ieeetr}
  65 \bibliography{a}
  66 \end{document}