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. It must be noted that the
  29 communication is not necessarily fast and thus these resources are scarce.
  30 Therefore the architecture tries to minimize the usage of communication
  31 resources.
  32
  33 \subsubsection{\iTasks{} $\rightarrow$ microcontroller}
  34 \input{commim.tex}
  35
  36 \subsubsection{Microcontroller $\rightarrow$ \iTasks{}}
  37 \input{commmi.tex}
  38
  39 \subsection{\iTasks{} task}
  40 \input{itasks.tex}
  41
  42 \section{Conclusion}
  43 \input{conclusion.tex}
  44
  45 \section{Improvements and future research}
  46 In the current implementation the number of possible tasks that can run
  47 simultaneously is fixed. A future project can implement dynamic task allocation
  48 and garbage collection that is then needed. Since memory is scarce on a
  49 microcontroller the program can not go and \verb#malloc# all the time to
  50 allocate new memory on the heap for the tasks. Over time this will cause
  51 fragmentation and eventually the program will run out of memory. A solution for
  52 this could be to let the engine handle the memory management and reorder and
  53 defragment the tasks on demand.
  54
  55 Another improvement could be the task scheduling. At the moment all tasks get
  56 one slice in which they are executed as a whole. Because of this the use of
  57 loops is not possible since a loop will block the entire program. A possible
  58 solution for this is to give different stack and program pointers to each task
  59 and save them separately. In this way the interpreter can slice the programs
  60 and pause one to let another run and through this it will be possible to add
  61 loops to the DSL and make the DSL even more imperative like.
  62
  63 \todo{Iets over task return values}
  64
  65 \todo{Iets over task combinators}
  66
  67 \bibliographystyle{ieeetr}
  68 \bibliography{a}
  69 \end{document}