.

[phd-thesis.git] / top / imp.tex

diff --git a/top/imp.tex b/top/imp.tex
index d33198b..1efd361 100644 (file)
--- a/top/imp.tex
+++ b/top/imp.tex
@@ -7,15 +7,19 @@
 \chapter{Implementation}%
 \label{chp:implementation}
 \begin{chapterabstract}
-       This chapter shows the implementation of the \gls{MTASK} system.
-       It is threefold: first it shows the implementation of the byte code compiler for \gls{MTASK}'s \gls{TOP} language, then is details of the implementation of \gls{MTASK}'s \gls{TOP} engine that executes the \gls{MTASK} tasks on the microcontroller, and finally it shows how the integration of \gls{MTASK} tasks and \glspl{SDS} is implemented both on the server and on the device.
+       \noindent This chapter shows the implementation of the \gls{MTASK} system by:
+       \begin{itemize}
+               \item shows the implementation of the byte code compiler for \gls{MTASK}'s \gls{TOP} language;
+               \item gives details of the implementation of \gls{MTASK}'s \gls{TOP} engine that executes the \gls{MTASK} tasks on the microcontroller;
+               \item and explains how the integration of \gls{MTASK} tasks and \glspl{SDS} is implemented both on the server and on the device.
+       \end{itemize}
 \end{chapterabstract}
 
 Microcontrollers usually have flash-based program memory which wears out fairly quick.
 For example, the atmega328p in the \gls{ARDUINO} UNO is rated for 10000 write cycles.
 While this sounds like a lot, if new tasks are sent to the device every minute or so, a lifetime of not even seven days is guaranteed.
 Hence, for dynamic applications, generating code at run-time for interpretation on the device is necessary.
-This byte code is then interpreted on MCUs with very little memory and processing power and thus save precious write cycles of the program memory.
+This byte code is then interpreted on microcontrollers with very little memory and processing power and thus save precious write cycles of the program memory.
 precious write cycles of the program memory.
 
 In order to provide the device with the tools to interpret the byte code, it is programmed with a \gls{RTS}, a customisable domain-specific \gls{OS} that takes care of the execution of tasks but also low-level mechanisms such as the communication, multi tasking, and memory management.
@@ -480,8 +484,7 @@ instance sds BCInterpret where
 \end{lstClean}
 % VimTeX: SynIgnore off
 
-
-\section{\texorpdfstring{\Gls{RTS}}{Run time system}}
+\section{\texorpdfstring{\Glsxtrlong{RTS}}{Run time system}}
 
 The \gls{RTS} is designed to run on systems with as little as \qty{2}{\kibi\byte} of \gls{RAM}.
 Aggressive memory management is therefore vital.
@@ -501,6 +504,8 @@ The event loop of the \gls{RTS} is executed repeatedly and consists of three dis
 \todo{plaa\-tje van me\-mo\-ry hier}
 \todo{pseu\-do\-code hier van de ex\-e\-cu\-tie}
 
+\subsection{C code generation}
+
 %TODO evt subsubsections verwijderen
 \subsection{Communication}
 In the first phase, the communication channels are processed.