with the server and interprets the \glspl{Task}.
\end{itemize}
-
\section{Devices}
The engine 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
the device software.
\begin{itemize}
\item \texttt{POSIX} compatible systems
-
+
This includes systems running \emph{Linux} and \emph{MacOS}.
\item \texttt{STM32} family microcontrollers supported by \texttt{ChibiOS}.
This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
development board.
\item Microcontrollers programmable by the \gls{Arduino} \gls{IDE}.\\
-
+
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}.
\end{itemize}
\section{Specification}
-The servers stores a description for every device available in a record type
+The server stores a description for every device available in a record type
which are stored in a \gls{SDS}. From the macro settings in
the interface file, a profile is created for the device that describes the
specification. When a connection between the server and a client is established
the server will send a request for specification. The client will serialize his
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}
+Listing~\ref{lst:devicespec} and stores the peripheral availability, the memory
+available for storing \glspl{Task} and \glspl{SDS}.
\begin{lstlisting}[label={lst:devicespec},
caption={Device specification for \glspl{mTask}}]
{ haveLed :: Bool
, haveAio :: Bool
, haveDio :: Bool
+ , aPins :: Int
+ , dPins :: Int
, bytesMemory :: Int
}
\end{lstlisting}
Listing~\ref{lst:mtaskdevice} with the accompanying classes and types.
The \CI{deviceResource} component of the record must implement the
-\CI{MTaskDuplex} interface that provides a function that launches a task used
-for synchronizing the channels. The \CI{deviceTask} stores the \gls{Task}-id
-for this \gls{Task} when active so that it can be checked upon. This top-level
-task has the duty to report thrown exceptions and occuring errors by setting
-the \CI{deviceError} field. All communication goes via these channels. If the
-system wants to send a message to the device it just puts it in the channels.
-Messages sent from the client to the server are also placed in there. In the
-case of the \gls{TCP} device type the \gls{Task} is just a 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{%
+\CI{MTaskDuplex} interface that provides a function that launches a \gls{Task}
+used for synchronizing the channels. The \CI{deviceTask} stores the
+\gls{Task}-id for this \gls{Task} when active so that it can be checked upon.
+This top-level task has the duty to report exceptions and errors as they are
+thrown by setting the \CI{deviceError} field. All communication goes via these
+channels. If the system wants to send a message to the device, it just puts it
+in the channels. Messages sent from the client to the server are also placed
+in there. In the case of the \gls{TCP} device type, the \gls{Task} is just a
+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}}.
Besides all the communication information, the record also keeps track of the
\subsection{\glspl{Task} \& \glspl{SDS}}
When a \gls{Task} is sent to the device it is added to the device record
without an identifier. The actual identifier is added to the record when the
-acknowledgement of the task by the device is received. The connection diagram
-is shown in Figure~\ref{fig:tasksend}.
+acknowledgement of the \gls{Task} by the device is received. The connection
+diagram is shown in Figure~\ref{fig:tasksend}.
\begin{figure}[H]
\centering
\caption{Sending a \gls{Task} to a device}\label{fig:tasksend}
\end{figure}
-The function for sending a task to the device is shown in
-Listing~\ref{lst:sendtask}. First the task is compiled into messages. The
+The function for sending a \gls{Task} to the device is shown in
+Listing~\ref{lst:sendtask}. First the \gls{Task} is compiled into messages. The
details of the compilation process are given in Section~\ref{sec:compiler}.
-The new shares that were made during compilation are added to the deviceshares
-that were made during the compilation are merged with the existing shares on
-the device. Furthermore the messages are placed in the channel share of the
-device. This will result in sending the actual \gls{SDS} specification and
-\gls{Task} specifications to the device. A \gls{Task} record is created with
-the identifier $-1$ to denote a \gls{Task} not yet acknowledged. Finally the
-device itself is updated with the new state and with the new \gls{Task}. When
-the device returns an acknowledgement the \gls{Task} is updated accordingly.
+The new \glspl{SDS} that were made during compilation are added to the
+deviceshares that were made during the compilation are merged with the existing
+shares on the device. Furthermore the messages are placed in the channel share
+of the device. This will result in sending the actual \gls{SDS} specification
+and \gls{Task} specifications to the device. A \gls{Task} record is created
+with the identifier $-1$ to denote a \gls{Task} not yet acknowledged. Finally
+the device itself is updated with the new state and with the new \gls{Task}.
+When the device returns an acknowledgement the \gls{Task} is updated
+accordingly.
\begin{lstlisting}[label={lst:sendtask},%
caption={Sending a \gls{Task} to a device}]
repositories / msc-thesis1617.git / blobdiff