functionality, this is analogous to the fact that views do not have to
implement all type classes in the \gls{EDSL}. When the device connects with
the server for the first time, the specifications of what is implemented is
-communicated.
+communicated. Devices must be available throughout sessions and cannot always
+be kept in scope and therefore they are stored in an \gls{SDS}.
At the time of writing the following device families are supported and can run
-the device software.
+the device software. Porting the client software to a new device does not
+require a lot of work. For example, porting to the \texttt{mbed} device family
+only took about an hour.
\begin{itemize}
\item \texttt{POSIX} compatible systems connected via the \gls{TCP}.
- This includes systems running \emph{Linux} and \emph{MacOS}.
+ This port only uses functionality from the standard \gls{C} library and
+ therefore runs on \emph{Linux} and \emph{MacOS}.
\item Microcontrollers supported by the
- \texttt{mbed}\footnote{\url{https://www.mbed.com/en/}}.
+ \texttt{mbed}\footnote{\url{https://mbed.com}}.
This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
development board.
\item Microcontrollers family supported by
- \texttt{ChibiOS}\footnote{\url{chibios.org}} connected via serial
- communication.
+ \texttt{ChibiOS}\footnote{\url{https://chibios.org}} connected via
+ serial communication.
This is also tested in particular on the \texttt{STM32f7x} series
\gls{ARM} development board.
other boards capable of running \gls{Arduino} code. A port of the
client has been made for the \texttt{ESP8266} powered \emph{NodeMCU}
that is connected via \gls{TCP} over WiFi. A port also has been made
- for the regular \gls{Arduino} \emph{UNO} board which only boasts a
+ for the regular \gls{Arduino} \emph{Uno} board which only boasts a
meager \emph{2K} \emph{RAM}. The stack size and storage available for
devices boasting this little \emph{RAM} has to be smaller than default
but are still suitable to hold a hand full of \glspl{Task}.
\subsection{Client}
\subsubsection{Engine}
-The client is in a constant loop listening for input and waiting to execute
+The client software is responsible for maintaining the communication and
+executing the \glspl{Task} when scheduled. In practise, this means that the
+client is in a constant loop, checking communication and executing
\glspl{Task}. The pseudocode for this is shown in Algorithm~\ref{alg:client}.
The \CI{input\_available} function waits for input, but has a timeout set which
can be interrupted. The timeout of the function determines the amount of loops
pointer to zero and the bottom respectively. When finished, the
interpreter executes one step at the time while the program counter is smaller
than the program length. This code is listed in Listing~\ref{lst:interpr}. One
-execution step is basically a big switch statement going over all possible
-bytecode instructions. Of some instructions, the implementations are shown in
-the listing. The \CI{BCPush} instruction is a little more complicated in the
-real code because some decoding will take place as not all \CI{BCValue}s are of
-the same length and are encoded.
+execution step is basically a switch statement going over all possible bytecode
+instructions. The implementation of some instructions is shown in the
+listing. The \CI{BCPush} instruction is a little more complicated in the real
+code because some decoding will take place as not all \CI{BCValue}s are of the
+same length and are encoded.
\begin{lstlisting}[language=C,label={lst:interpr},%
caption={Rough code outline for interpretation}]
repositories / msc-thesis1617.git / commitdiff