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{2KB} RAM. The stack size and storage available for
- devices boasting this little 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.