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 \section{Introduction}
   9 \input{intro.tex}
  10
  11 \section{mTasks}
  12 The current implementation of \emph{mTask}s can be used to generate \emph{C}
  13 code that will run a mini-taskserver on a microcontroller. This project will
  14 strip the original \emph{mTask} of this functionality and embed communication
  15 in the system.
  16
  17 \section{Microcontroller}
  18 Every microcontroller will run the \emph{mTask-engine}. This engine is a
  19 program that has two jobs. The first job of the engine is to listen to the
  20 \iTasks{} server to which it is connected via one of the aforementioned
  21 methods. The \iTasks{} server can send task specifications and SDS
  22 specifications to the engine to process. Moreover the \iTasks{} server can send
  23 requests for termination of tasks.
  24
  25 The second job of the engine is to run the tasks in a round robin fashion.
  26 Every task has a frequency of execution and when the task want a turn he will
  27 be executed by the engine through interpreting the bytecode. Tasks can change
  28 SDS's and therefore the engine also has to keep the \iTasks{} server updated
  29 with the changes. The specifics of this are explained in detail later on.
  30
  31 \section{Communication}
  32 We can divide the communication up into two parts. Communication from the
  33 \iTasks{} server to the microcontroller and vice versa. The means of
  34 communicating are unimportant, this can be TCP, Serial or any other
  35 communication method that sends data in a linear way.
  36
  37 \subsection{\iTasks{} $\rightarrow$ microcontroller}
  38 The \iTasks{} server can send two types of messages. The first and most
  39 important type is sending a new task to the server. Tasks are dynamically sent
  40 to the microcontroller, this means that the engine in itself does not do
  41 anything without it getting a task first from the server. When a task is sent
  42 the microcontroller acknowledges the message by sending the associated task
  43 identification number back to the for the server to use in the future.
  44 The second task is sending SDS specifications to the engine to tell the engine
  45 what type of SDS will be used in the tasks so that it can be allocated. The
  46 message structure for sending a task is shown in Table~\ref{tbl:tasksend} and
  47 the message of sending an SDS specification is shown in
  48 Table~\ref{tbl:sdsspec}.
  49 \begin{table}[h]
  50         \centering
  51         \begin{tabular}{ll}
  52                 \toprule
  53                 Bytes & Description\\
  54                 \midrule
  55                 \multicolumn{2}{c}{\textbf{Request}}\\
  56                 $1$ & Task send code \verb#'t'#\\
  57                 $2-3$ & Frequency in number of milliseconds as a 16-bit integer\\
  58                 $4-5$ & Length of the bytecode 16-bit integer\\
  59                 $n$ & Bytecode for the task\\
  60                 \midrule
  61                 \multicolumn{2}{c}{\textbf{Response}}\\
  62                 $1$ & Task numeric identification\\
  63                 \bottomrule
  64         \end{tabular}
  65         \caption{Message format for sending a task}\label{tbl:tasksend}
  66 \end{table}
  67
  68 \begin{table}[h]
  69         \centering
  70         \begin{tabular}{ll}
  71                 \toprule
  72                 Bytes & Description\\
  73                 \midrule
  74                 \multicolumn{2}{c}{\textbf{Request}}\\
  75                 $1$ & SDS send code \verb#'s'#\\
  76                 $2-3$ & SDS length as a 16-bit integer\\
  77                 $n$ & Value of the SDS identifier\\
  78                 \midrule
  79                 \multicolumn{2}{c}{\textbf{Response}}\\
  80                 $1$ & SDS numeric identification\\
  81                 \bottomrule
  82         \end{tabular}
  83         \caption{Message format for sending an SDS specification}\label{tbl:sdssend}
  84 \end{table}
  85
  86 \subsection{Microcontroller $\rightarrow$ \iTasks{}}
  87 The only thing the microcontroller has to communicate back with the server is
  88 an update of the SDS and a request for an SDS value.
  89 Since all SDSs have a numeric identifier the engine can just send a request
  90 message with the identifier to the server. A detailed description of the
  91 message for sending and receiving SDSs is described in
  92 Tables~\ref{tbl:sdssend},~\ref{tbl:sdsrecv}.
  93
  94 As said before, publication of SDS values is not done automatically to save
  95 bandwidth. Therefore the tasks need to have a way of requesting the latest SDS
  96 value and a way of publishing an updated value. This is elaborated more upon in
  97 the next section.
  98
  99 \begin{table}[h]
 100         \centering
 101         \begin{tabular}{ll}
 102                 \toprule
 103                 Bytes & Description\\
 104                 \midrule
 105                 $1$ & SDS send code \verb#'s'#\\
 106                 $2-3$ & SDS identifier as a 16-bit integer\\
 107                 $4-5$ & Length of the message 16-bit integer\\
 108                 $n$ & Value of the SDS identifier\\
 109                 \bottomrule
 110         \end{tabular}
 111         \caption{Message format for a SDS-send operation}\label{tbl:sdssend}
 112 \end{table}
 113
 114 \begin{table}[h]
 115         \centering
 116         \begin{tabular}{ll}
 117                 \toprule
 118                 Bytes & Description\\
 119                 \midrule
 120                 \multicolumn{2}{c}{\textbf{Request}}\\
 121                 $1$ & SDS send code \verb#'r'#\\
 122                 $2-3$ & SDS identifier as a 16-bit integer\\
 123                 \midrule
 124                 \multicolumn{2}{c}{\textbf{Response}}\\
 125                 $1-2$ & Length of the message as a 16-bit integer\\
 126                 $n$ & Value of the SDS\\
 127                 \bottomrule
 128         \end{tabular}
 129         \caption{Message format for a SDS-receive operation}\label{tbl:sdsrecv}
 130 \end{table}
 131
 132 \section{Improvements and future research}
 133 In the current implementation the number of possible tasks that can run
 134 simultaneously is fixed. A future project can implement dynamic task allocation
 135 and garbage collection that is then needed. Since memory is scarce on a
 136 microcontroller the program can not go and \verb#malloc# all the time to
 137 allocate new memory on the heap for the tasks. Over time this will cause
 138 fragmentation and eventually the program will run out of memory. A solution for
 139 this could be to let the engine handle the memory management and reorder and
 140 defragment the tasks on demand.
 141
 142 Another improvement could be the task scheduling. At the moment all tasks get
 143 one slice in which they are executed as a whole. Because of this the use of
 144 loops is not possible since a loop will block the entire program. A possible
 145 solution for this is to give different stack and program pointers to each task
 146 and save them separately. In this way the interpreter can slice the programs
 147 and pause one to let another run and through this it will be possible to add
 148 loops to the DSL and make the DSL even more imperative like.
 149
 150 \bibliographystyle{ieeetr}
 151 \bibliography{a}
 152 \end{document}