From b8953a28b8a7db87f446bc74a6e6f854e19cd639 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Sat, 1 Jul 2017 16:49:33 +0200 Subject: [PATCH] started with sweep through arch.itasks --- arch.communication.tex | 26 ++++++++++++++++++ arch.devices.tex | 2 +- arch.itasks.tex | 62 ++++++++++++++++++------------------------ arch.tex | 2 +- 4 files changed, 55 insertions(+), 37 deletions(-) diff --git a/arch.communication.tex b/arch.communication.tex index 4585a06..7da8ad1 100644 --- a/arch.communication.tex +++ b/arch.communication.tex @@ -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 diff --git a/arch.devices.tex b/arch.devices.tex index 8e0c181..b43a40f 100644 --- a/arch.devices.tex +++ b/arch.devices.tex @@ -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. diff --git a/arch.itasks.tex b/arch.itasks.tex index 7f9ac60..7a21471 100644 --- a/arch.itasks.tex +++ b/arch.itasks.tex @@ -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 diff --git a/arch.tex b/arch.tex index f854a18..e1ae608 100644 --- 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]% -- 2.20.1