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.
This is also tested in particular on the \texttt{STM32f7x} series
\gls{ARM} development board.
- \item Microcontrollers which are programmable in the \gls{Arduino} \gls{IDE}
- connected via serial communication or via \gls{TCP} over WiFi or
- Ethernet.
+ \item Microcontrollers which are programmable in the \gls{Arduino}
+ \gls{IDE} connected via serial communication or via \gls{TCP} over WiFi
+ or Ethernet.
This does not only include \gls{Arduino} compatible boards but also
other boards capable of running \gls{Arduino} code. A port of the
- client has been made for the \texttt{ESP8266} powered \emph{NodeMCU}
+ client has been made for the \textsc{ESP8266} powered \textsc{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
+ for the regular \gls{Arduino} Uno board which only boasts a
+ meager \emph{2K} RAM. The stack size and storage available % chktex 13
+ 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}
memory on the heap are not very space optimal and often leave holes in the heap
if allocations are not freed in a last in first out fashion. To overcome this
problem, the client will allocate a big memory segment in the global data
-block. This block of memory resides under the stack and its size can be set in
+block. This block of memory resides under the stack and its size can be set in
the interface implementation. This block of memory will be managed in a similar
way as the entire memory space of the device is managed. \Glspl{Task} will grow
from the bottom up and \glspl{SDS} will grow from the top down.
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