\section{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 --- excluding the
device specific settings --- is 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
for the first time with a server the specifications of what is implemented is
communicated.

At the time of writing the following device families are supported and can run
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 \emph{Arduino} \gls{IDE}.\\
		
		This does not only include \emph{Arduino} compatible boards but also
		other boards capable of running \emph{Arduino} code. The code
		has been found working on the \texttt{ESP8266} powered \emph{NodeMCU}.
		It is tested on devices as small as the regular \emph{Arduino UNO}
		board that only boasts a meager \emph{2K} of \emph{RAM}.
\end{itemize}

\section{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 specification
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}

\section{Communication}
The communication to and fro a device runs via a single \gls{SDS}. Every
device has a specific resource that is used to connect to the device. The
current system supports connecting devices via a serial connection and via a
\gls{TCP} connection. Every device has the type \CI{MTaskDevice} and which
is listed in Listing~\ref{lst:mtaskdevice}. When a device is added, a background
\gls{Task} is started that runs the \CI{synFun}. The \CI{synFun} is the task that
synchronizes the channel \gls{SDS} with the actual device. For the \gls{TCP}
device this is a simple \CI{tcpconnect}. The \CI{TaskId} of the background task
is saved to be able to stop the task in the future. When the task is unable to
connect it will set the \CI{deviceError} field to notify the user.
\todo{netter maken}

\begin{lstlisting}[language=Clean,caption={Device type},label={lst:mtaskdevice}]
:: Channels :== ([MTaskMSGRecv], [MTaskMSGSend], Bool)
:: MTaskResource 
	= TCPDevice TCPSettings
	| SerialDevice TTYSettings
:: MTaskDevice =
		{ deviceTask :: Maybe TaskId
		, deviceError :: Maybe String
		, deviceChannels :: String
		, deviceName :: String
		, deviceTasks :: [MTaskTask]
		, deviceData :: MTaskResource
		, deviceSpec :: Maybe MTaskDeviceSpec
		, deviceShares :: [MTaskShare]
	}

class MTaskDuplex a where
	synFun :: a (Shared Channels) -> Task ()
\end{lstlisting}
