X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=arch.itasks.tex;fp=arch.itasks.tex;h=7f9ac60df778c3654739ec2e946e2f3ff38f1f84;hb=b3f05abd18320bba213273d3433e8fb2c2ac4228;hp=f7fc915e2a4fb11c9b42aa7688a83838cd2b139e;hpb=47820995aae3c8666173d17018ba6d09f8a3d9ff;p=msc-thesis1617.git

diff --git a/arch.itasks.tex b/arch.itasks.tex
index f7fc915..7f9ac60 100644
--- a/arch.itasks.tex
+++ b/arch.itasks.tex
@@ -5,6 +5,31 @@ interactive management console for the \gls{mTask} system. This interface
 provides functionality to list \glspl{SDS}, add and remove \glspl{Task},
 administrate devices and view the state of the system.
 
+\subsection{Device Specification}
+The server stores a description for every device available in a record type.
+From the macro settings in the interface file, a profile is created that
+describes the specification of the device. When the connection between the
+server and a client is established, the server will send a request for
+specification. The client serializes its specification and send it to the
+server so that the server knows what the client is capable of. The exact
+specification is shown in Listing~\ref{lst:devicespec} and stores the
+peripheral availability, the memory available for storing \glspl{Task} and
+\glspl{SDS} and the size of the stack. Not all peripheral flags are shown for
+brevity. The encoding for this interface 
+
+\begin{lstlisting}[label={lst:devicespec},
+	caption={Device specification for \gls{mTask}-\glspl{Task}}]
+:: MTaskDeviceSpec =
+	{ haveLed     :: Bool
+	, haveLCD     :: Bool
+	, have...
+	, bytesMemory :: Int
+	, stackSize   :: Int
+	, aPins       :: Int
+	, dPins       :: Int
+	}
+\end{lstlisting}
+
 \subsection{Device Storage}
 Everything that a device encompasses is stored in the \CI{MTaskDevice} record
 type. This includes management for the \glspl{SDS} and \glspl{Task} stored on
@@ -29,7 +54,7 @@ types.
 		, deviceResource :: MTaskResource
 		, deviceSpec     :: Maybe MTaskDeviceSpec
 		, deviceShares   :: [MTaskShare]
-	}
+		}
 
 channels :: MTaskDevice -> Shared Channels
 
@@ -59,17 +84,16 @@ is given in Listing~\ref{lst:mtaskdevice}. The definitions of the message
 format are explained in the following section.
 
 \subsection{Shares}
-The system keeps track of the \glspl{SDS} stored on
-the client in a big \gls{SDS} containing a list of devices. Client-\glspl{SDS}
-can be stored on one device at the same time. This means that if an \gls{SDS}
-updates, everyone watching it will be notified. This would result in a lot
-of notifications that are not meant for the watcher. Moreover, when a client
-updates the \gls{SDS} this is processed by the connection handler and results
-in an update of the real \gls{SDS}. Finally, the \gls{SDS} of a client must be
-synchronized with the actual device. Thus, when an \gls{iTasks}-\gls{Task}
-writes the client-\gls{SDS}, it must be propagated to the real device. There
-are several ways of tackling this problem each with their own level of
-granularity.
+The system keeps track of the \glspl{SDS} stored on the client in a big
+\gls{SDS} containing a list of devices. Client-\glspl{SDS} can be stored on one
+device at the same time. This means that if an \gls{SDS} updates, everyone
+watching it will be notified. This would result in a lot of notifications that
+are not meant for the watcher. Moreover, when a client updates the \gls{SDS}
+this is processed by the connection handler and results in an update of the
+real \gls{SDS}. Finally, the \gls{SDS} of a client must be synchronized with
+the actual device. Thus, when an \gls{iTasks}-\gls{Task} writes the
+client-\gls{SDS}, it must be propagated to the real device. There are several
+ways of tackling this problem each with their own level of granularity.
 
 First an actual \gls{iTasks}-\gls{SDS} for every \gls{SDS} used in a client can
 be instantiated with one \gls{iTasks}-\gls{Task} listening to the \gls{SDS} and