X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=arch.devices.tex;h=c06d96493230dc8f775b45cf5467f2a5b1a24e2d;hb=4bb4ae51e1199aa618d8765b0bc429fba9055140;hp=db56b4887f3aee278860c75d01e0d280ad84462e;hpb=d098cf66624230390d762e9995e8fd61b0d3c71d;p=msc-thesis1617.git

diff --git a/arch.devices.tex b/arch.devices.tex
index db56b48..c06d964 100644
--- a/arch.devices.tex
+++ b/arch.devices.tex
@@ -2,19 +2,18 @@ A device is suitable for the system as a client if it can run the engine.
 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}.
@@ -22,7 +21,7 @@ only took about an hour.
 		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.
@@ -41,8 +40,8 @@ only took about an hour.
 		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 % 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}
 
@@ -114,11 +113,11 @@ memory space are reordered in such a way that there are no holes left. In
 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}.