.

diff --git a/arch.devices.tex b/arch.devices.tex
index cca4449..32e28fd 100644 (file)
--- a/arch.devices.tex
+++ b/arch.devices.tex
@@ -1,13 +1,13 @@
-A device is suitable for the system if it can run the engine.
+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
+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
+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.
 
@@ -17,11 +17,17 @@ the device software.
        \item \texttt{POSIX} compatible systems connected via the \gls{TCP}.
 
                This includes systems running \emph{Linux} and \emph{MacOS}.
-       \item The \texttt{STM32} microcontrollers family supported by
-               \texttt{ChibiOS} connected via serial communication.
+       \item Microcontrollers supported by the
+               \texttt{mbed}\footnote{\url{https://www.mbed.com/en/}}.
 
                This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
                development board.
+       \item Microcontrollers family supported by
+               \texttt{ChibiOS}\footnote{\url{chibios.org}} connected via serial
+               communication.
+
+               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.
@@ -77,17 +83,17 @@ device.
 \end{algorithm}
 
 \subsubsection{Storage}
-\glspl{Task} and \glspl{SDS} are stored on the client in memory. Some devices
-have very little memory and therefore memory space is very expensive and needs
-to be used optimally. Almost all microcontrollers 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 reverse order. 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 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.
+\glspl{Task} and \glspl{SDS} are stored on the client not in program memory but
+in memory. Some devices have very little memory and therefore memory space is
+very expensive and needs to be used optimally. Almost all microcontrollers
+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
+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.
 
 When a \gls{Task} is received, the program will traverse the memory space from
 the bottom up, jumping over all \glspl{Task}. A \gls{Task} is stored as the
@@ -97,18 +103,19 @@ to determine the size of the \gls{Task}. When the program arrived at the last
 copied to there. This method is analogously applied for \glspl{SDS}, however,
 the \glspl{SDS} grow from the bottom down.
 
-When a \gls{Task} or \gls{SDS} is removed, all remaining objects are compressed
-again. This means that if the first received \gls{Task} is removed, all
+When a \gls{Task} or \gls{SDS} is removed, all the remaining objects in the
+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}. If this technique would not be used 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.
+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 them in memory for
-\glspl{Task} and \glspl{SDS} are shown in Listing~\ref{lst:structs}.
+The structure instances and helper functions for traversing for \glspl{Task}
+and \glspl{SDS} are shown in Listing~\ref{lst:structs}.
 
 \begin{lstlisting}[language=C,label={lst:structs},%
        caption={The data type storing the \glspl{Task}},float]
@@ -177,29 +184,8 @@ void run_task(struct task *t){
                case BCJMPT: trace("jmpt to %d", program[pc]);
                        pc = stack[--sp] ? program[pc]-1 : pc+1;
                        break;
-}
-\end{lstlisting}
-
-\subsection{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.
-
-\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}

diff --git a/arch.itasks.tex b/arch.itasks.tex
index f7fc915..7f9ac60 100644 (file)
--- 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

diff --git a/arch.tex b/arch.tex
index c5e46ee..f854a18 100644 (file)
--- a/arch.tex
+++ b/arch.tex
@@ -5,9 +5,9 @@ to bytecode by the \gls{mTask}-view --- to the device. The device runs an
 interpreter which executes the \gls{Task}'s bytecode following the provided
 scheduling strategy. Devices added to the system are stored and get a profile
 for identification. These profiles are persistent during reboots of the
-\gls{iTasks}-system to allow for easy reconnecting with old devices. The
-way of interacting with \gls{mTask}-\gls{Task} is analogous to interacting
-with \gls{iTasks}-\glspl{Task}. This means that programmers can access the
+\gls{iTasks}-system to allow for easy reconnecting with old devices. The way of
+interacting with \gls{mTask}-\gls{Task} is analogous to interacting with
+\gls{iTasks}-\glspl{Task}. This means that programmers can access the
 \glspl{SDS} made for a device in the same way as regular \glspl{SDS} and they
 can execute, combine and transform \gls{mTask}-\glspl{Task} as if they where
 normal \gls{iTasks}-\glspl{Task}.