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 In \emph{Task Oriented Programming} (TOP) a program is built out of pieces of
  10 work called \emph{tasks}~\cite{achten_introduction_2015}. Tasks differ from
  11 function in the way that they return a result. A task's return value can change
  12 over time. Task exist in many forms and they can be composed sequentially and
  13 in parallel. Some possible tasks are asking for user input via a web browser,
  14 setting up a TCP connection to another server or combining several tasks. At
  15 the moment there are several types of leaf tasks. A leaf task is a task that
  16 does not consist of tasks itself. Examples of leaf tasks are  the so called
  17 editors.
  18
  19 This paper describes the effort to add another type of leaf task that
  20 focusses on microcontrollers. Microcontrollers are often not powerful
  21 enough to run a full-fledged task server and therefore there is the need to
  22 introduce special microcontroller tasks. Effort for this is already made by by
  23 the department~\cite{koopman_tasks_2016}. However, communication between the
  24 \emph{mTask} and the iTasks system is still lacking and exactly that will be the
  25 goal of the project. This requires adding a new type of leaf task that allows
  26 the user to run \emph{mTasks} on microcontrollers. The leaf task should
  27 abstract away from communication techniques and it should be relatively easy to
  28 add techniques. Techniques that are interesting to experiment with is Serial
  29 communication, Bluetooth, \textsc{WiFi}, \textsc{GSM} and \textsc{LoRa}.
  30
  31 \section{mTasks}
  32 The current implementation of \emph{mTask}s can be used to generate \emph{C}
  33 code that will run a mini-taskserver on a microcontroller. This project will
  34 strip the original \emph{mTask} of this functionality and embed communication
  35 in the system.
  36
  37 \section{Microcontroller}
  38 Every microcontroller will run the \emph{mTask-engine}. This engine is a
  39 program that has two jobs. The first job of the engine is to listen to the
  40 \iTasks{} server to which it is connected via one of the aforementioned
  41 methods. The \iTasks{} server can send task specifications and SDS
  42 specifications to the engine to process.
  43
  44 The second job of the engine is to run the tasks in a round robin fashion.
  45 Every task has a frequency of execution and when the task want a turn he will
  46 be executed by the engine through interpreting the bytecode. Tasks can change
  47 SDS's and therefore the engine also has to keep the \iTasks{} server updated
  48 with the changes. The specifics of this are explained in detail later on.
  49
  50 \section{Communication}
  51 We can divide the communication up into two parts. Communication from the
  52 \iTasks{} server to the microcontroller and vice versa. The means of
  53 communicating are unimportant, this can be TCP, Serial or any other
  54 communication method that sends data in a linear way.
  55
  56 \subsection{\iTasks{} $\rightarrow$ microcontroller}
  57
  58
  59 \subsection{Microcontroller $\rightarrow$ \iTasks{}}
  60 The only thing the microcontroller has to communicate back with the server is
  61 an update of the SDS and a request for an SDS value.
  62 Since all SDS's have a numeric identifier the engine can just send a request
  63 message with the identifier to the server. A detailed description of the
  64 message is described in Table~\ref{tbl:sdssend}.
  65
  66 \begin{table}[H]
  67         \centering
  68         \begin{tabular}{ll}
  69                 \toprule
  70                 Bytes & Description\\
  71                 \midrule
  72                 $1$ & SDS send code \verb#'s'#\\
  73                 $2-5$ & SDS identifier as a 16-bit integer\\
  74                 $2-5$ & Length of the message 16-bit integer\\
  75                 $n$ & Value of the SDS identifier\\
  76                 \bottomrule
  77         \end{tabular}
  78         \caption{Message format for a SDS-send operation}\label{tbl:sdssend}
  79 \end{table}
  80
  81 \section{Improvements and future research}
  82 In the current implementation the number of possible tasks that can run
  83 simultaneously is fixed. A future project can implement dynamic task allocation
  84 and garbage collection that is then needed. Since memory is scarce on a
  85 microcontroller the program can not go and \verb#malloc# all the time to
  86 allocate new memory on the heap for the tasks. Over time this will cause
  87 fragmentation and eventually the program will run out of memory. A solution for
  88 this could be to let the engine handle the memory management and reorder and
  89 defragment the tasks on demand.
  90
  91 Another improvement could be the task scheduling. At the moment all tasks get
  92 one slice in which they are executed as a whole. Because of this the use of
  93 loops is not possible since a loop will block the entire program. A possible
  94 solution for this is to give different stack and program pointers to each task
  95 and save them separately. In this way the interpreter can slice the programs
  96 and pause one to let another run and through this it will be possible to add
  97 loops to the DSL and make the DSL even more imperative like.
  98
  99 \bibliographystyle{ieeetr}
 100 \bibliography{a}
 101 \end{document}