\section{Architecture}
\subsection{Devices}
The client code 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
and 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, listed in
Appendix~\label{app:device-interface}\todo{update interface listing}, also
includes functions for accessing the peripherals that not every device might
have. Devices can choose what to implement by setting the correct macros in the
top of the file. When a server connects to a client the specifications are
communicated.

The current list of supported and tested devices is as follows:
\begin{itemize}
	\item $^*$\texttt{NIX} systems such as Linux
	\item STM32 like development boards supported by \texttt{ChibiOS}.
	\item \emph{Arduino} compatible microcontrollers
\end{itemize}

\subsection{Specification}
Devices are stored in a record type and all devices in the system are stored in
a \gls{SDS} containing all devices. 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 specs and send
it to the server so that the server knows what the client is capable of. The
exact specification is listed in Listing~\ref{lst:devicespec}

\begin{lstlisting}[language=Clean,label={lst:devicespec},
	caption={Device specification for \glspl{mTask}}]
:: MTaskDeviceSpec =
	{haveLed     :: Bool
	,haveAio     :: Bool
	,haveDio     :: Bool
	,bytesMemory :: Int
	}
\end{lstlisting}
\todo{Explain specification, combine task and share space}

\subsection{Communication}
