X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=results.arch.tex;h=e33dc47674357c25b15f68f2da9fc955b940c60d;hb=435b0d98d22a47530f50ff82f2451e70ce2bed96;hp=fde75c0cae261424f38ed47594e836858210bea5;hpb=d118ff9d857683084065145df45135ef6fa06711;p=msc-thesis1617.git

diff --git a/results.arch.tex b/results.arch.tex
index fde75c0..e33dc47 100644
--- a/results.arch.tex
+++ b/results.arch.tex
@@ -1,13 +1,13 @@
 \section{Devices}
 The client code for the devices is compiled from one codebase. For a device to
-be eligible for \glspl{mTask} it must be able to compile the shared codebase
+be eligible for \glspl{mTask}, it must be able to compile the shared codebase
 and 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
+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
 for the first time with a server the specifications of what is implemented is
 communicated.
@@ -22,13 +22,13 @@ the device software.
 
 		This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
 		development board.
-	\item Microcontrollers programmable by the \emph{Arduino} \gls{IDE}.\\
+	\item Microcontrollers programmable by the \gls{Arduino} \gls{IDE}.\\
 		
-		This does not only include \emph{Arduino} compatible boards but also
-		other boards capable of running \emph{Arduino} code. The code
+		This does not only include \gls{Arduino} compatible boards but also
+		other boards capable of running \gls{Arduino} code. The code
 		has been found working on the \texttt{ESP8266} powered \emph{NodeMCU}.
-		It is tested on devices as small as the regular \emph{Arduino UNO}
-		board that only boasts a meager \emph{2K} of \emph{RAM}.
+		It is tested on devices as small as the regular \gls{Arduino}
+		\emph{UNO} board that only boasts a meager \emph{2K} of \emph{RAM}.
 \end{itemize}
 
 \section{Specification}
@@ -55,8 +55,8 @@ The communication to and fro a device runs via a single \gls{SDS}. Every
 device has a specific resource that is used to connect to the device. The
 current system supports connecting devices via a serial connection and via a
 \gls{TCP} connection. Every device has the type \CI{MTaskDevice} and which
-is listed in Listing~\ref{lst:mtaskdevice}. When a device is added a background
-task is started that runs the \CI{synFun}. The \CI{synFun} is the task that
+is listed in Listing~\ref{lst:mtaskdevice}. When a device is added, a background
+\gls{Task} is started that runs the \CI{synFun}. The \CI{synFun} is the task that
 synchronizes the channel \gls{SDS} with the actual device. For the \gls{TCP}
 device this is a simple \CI{tcpconnect}. The \CI{TaskId} of the background task
 is saved to be able to stop the task in the future. When the task is unable to
@@ -76,6 +76,7 @@ connect it will set the \CI{deviceError} field to notify the user.
 		, deviceTasks :: [MTaskTask]
 		, deviceData :: MTaskResource
 		, deviceSpec :: Maybe MTaskDeviceSpec
+		, deviceShares :: [MTaskShare]
 	}
 
 class MTaskDuplex a where