Merge branch 'master' of git.martlubbers.net:msc-thesis1617
[msc-thesis1617.git] / arch.devices.tex
index 20d0621..16e2a50 100644 (file)
@@ -31,17 +31,17 @@ only took about an hour.
 
                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}
 
@@ -95,7 +95,7 @@ support heaps nowadays, however, the functions for allocating and freeing the
 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.