started with sweep through arch.itasks
authorMart Lubbers <mart@martlubbers.net>
Sat, 1 Jul 2017 14:49:33 +0000 (16:49 +0200)
committerMart Lubbers <mart@martlubbers.net>
Sat, 1 Jul 2017 14:49:33 +0000 (16:49 +0200)
arch.communication.tex
arch.devices.tex
arch.itasks.tex
arch.tex

index 4585a06..7da8ad1 100644 (file)
@@ -26,6 +26,32 @@ and according actions will be given in the following subsections.
 :: MTaskInterval = OneShot | OnInterval Int | OnInterrupt Int
 \end{lstlisting}
 
+\subsection{Device Specification}
+The server stores a description for every device available in a record type.
+From the macro settings in the client --- 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.
+
+\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{Add a device}
 A device can be added by filling in the \CI{MTaskDevice} record as much as
 possible and running the \CI{connectDevice} function. This function grabs the
index 8e0c181..b43a40f 100644 (file)
@@ -22,7 +22,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}}.
+               \texttt{mbed}\footnote{\url{https://mbed.com}} environment.
 
                This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
                development board.
index 7f9ac60..7a21471 100644 (file)
@@ -1,45 +1,25 @@
 The server part of the system is written in \gls{iTasks}. Functions for
-managing devices, \glspl{Task} and \glspl{SDS} have been created to support the
-functionality. An interactive web application has been created that provides an
-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}
+managing devices, \glspl{Task} and \glspl{SDS} are available. Furthermore, an
+interactive web application has been created that provides an 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 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
-the device. The \CI{MTaskDevice} definition is shown in
-Listing~\ref{lst:mtaskdevice} accompanied with the necessary classes and sub
-types.
+type which is in turn stored in a \gls{SDS}. This includes management for the
+\glspl{SDS} and \glspl{Task} stored on the device. The \CI{MTaskDevice}
+definition is shown in Listing~\ref{lst:mtaskdevice} accompanied with the
+necessary classes and sub types. Devices added to the system must be reachable
+asynchronously. This implicates that the programmer only needs to keep hold of
+the reference to the device and not the actual device record.
 
 \begin{lstlisting}[caption={Device type},label={lst:mtaskdevice}]
 :: Channels :== ([MTaskMSGRecv], [MTaskMSGSend], Bool)
-:: BCState = ... // Compiler state, explained in later sections
+:: BCState = ...         // Compiler state, explained in later sections
+:: MTaskDeviceSpec = ... // Also explained in later sections
+:: MTaskMSGRecv = ...    // Message format, explained in later sections
+:: MTaskMSGSend = ...    // Also explained in later sections
 :: MTaskResource
        = TCPDevice TCPSettings
        | SerialDevice TTYSettings
@@ -75,6 +55,8 @@ simple wrapper around the existing \CI{tcpconnect} function in \gls{iTasks}. In
 case of a device connected by a serial connection, it uses the newly developed
 serial port library of \gls{Clean}\footnote{\url{%
 https://gitlab.science.ru.nl/mlubbers/CleanSerial}}.
+The implementation and semantics for the \CI{MTaskMSGRecv} and
+\CI{MTaskMSGSend} types is given in Section~\ref{sec:communication}.
 
 Besides all the communication information, the record also keeps track of the
 \glspl{Task} currently on the device, the compiler state (see
@@ -84,6 +66,16 @@ is given in Listing~\ref{lst:mtaskdevice}. The definitions of the message
 format are explained in the following section.
 
 \subsection{Shares}
+\Glspl{SDS} on the device are synchronized in the server and thus stored both
+on the server and on the client. In this way the communication is kept to the
+bare minimum because no communication with the device is needed for a
+\gls{SDS} read operation. In this case the \gls{Task} requesting can just be
+provided with the synchronized value. As mentioned before, the device has to
+explicitly publish an update. This has the implication that the server and the
+client can get out of sync. However, this is not a problem since it is well
+documented and by design.
+
+% TODO
 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
index f854a18..e1ae608 100644 (file)
--- a/arch.tex
+++ b/arch.tex
@@ -18,7 +18,7 @@ normal \gls{iTasks}-\glspl{Task}.
 \section{iTasks}
 \input{arch.itasks}
 
-\section{Communication}
+\section{Communication}\label{sec:communication}
 \input{arch.communication}
 
 \section[Lifting mTasks to iTasks-Tasks]%