The engine is compiled from one codebase and devices implement (part of) the
device specific interface. The shared codebase only uses standard \gls{C} and
no special libraries or tricks are used. Therefore, the code is compilable for
-almost any device or system. Note that it is not needed to implement a full
-interface. The full interface --- excluding the device specific settings --- is
-listed in Appendix~\ref{app:device-interface}. The interface works in a
-similar fashion as the \gls{EDSL}. Devices do not have to implement all
-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. Devices must be available throughout sessions and cannot always
-be kept in scope and therefore they are stored in an \gls{SDS}.
+almost any device or system. The full interface --- excluding the device
+specific settings --- is listed in Appendix~\ref{app:device-interface}. The
+interface works in a similar fashion as the \gls{EDSL}. Devices do not have to
+implement all 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. 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. Porting the client software to a new device does not
-require a lot of work. For example, porting to the \texttt{mbed} device family
+require a lot of work. For example, porting to the \gls{mbed} device family
only took about an hour.
\begin{itemize}
\item \texttt{POSIX} compatible systems connected via the \gls{TCP}.
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://mbed.com}} environment.
+ \gls{mbed}\footnote{\url{https://mbed.com}} environment.
This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
development board.
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
- meager \emph{2K} \emph{RAM}. The stack size and storage available for
- devices boasting this little \emph{RAM} has to be smaller than default
+ meager \emph{2KB} RAM. The stack size and storage available for
+ devices boasting this little RAM has to be smaller than default
but are still suitable to hold a hand full of \glspl{Task}.
\end{itemize}
practice this means that if the first received \gls{Task} is removed, all
\glspl{Task} received later will have to move back. Obviously, this is quite
time intensive but it can not be permitted to leave holes in the memory since
-the memory space is so limited. This techniques allows for even the smallest
-tested microcontrollers with only $2K$ \emph{RAM} to hold several \glspl{Task}
-and \glspl{SDS}. Without this technique, the memory space will decrease over
-time and the client can then not run for very long since holes are evidently
-created at some point.
+the memory space is so limited. With this technique, even the smallest
+tested microcontrollers with only $2K$ RAM can hold several \glspl{Task} and
+\glspl{SDS}. Without this technique, the memory space will decrease over time
+and the client can then not run for very long since holes are evidently created
+at some point.
The structure instances and helper functions for traversing for \glspl{Task}
and \glspl{SDS} are shown in Listing~\ref{lst:structs}.
repositories / msc-thesis1617.git / blobdiff