add bit about communication

[msc-thesis1617.git] / methods.arch.tex

diff --git a/methods.arch.tex b/methods.arch.tex
index 3cf1487..cd9918d 100644 (file)
--- a/methods.arch.tex
+++ b/methods.arch.tex
@@ -5,18 +5,31 @@ 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
 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
+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.
 
 communicated.
 

-The current list of supported and tested devices is as follows:
+At the time of writing the following device families are supported and can run
+the device software.

 \begin{itemize}
 \begin{itemize}

-       \item $^*$\texttt{NIX} systems such as Linux
-       \item STM32 like development boards supported by \texttt{ChibiOS}.
-       \item \emph{Arduino} compatible microcontrollers
+       \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}
 
 \subsection{Specification}
 \end{itemize}
 
 \subsection{Specification}


@@ -24,9 +37,9 @@ 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
 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}
+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}}]
 
 \begin{lstlisting}[language=Clean,label={lst:devicespec},
        caption={Device specification for \glspl{mTask}}]


@@ -37,6 +50,38 @@ exact specification is listed in Listing~\ref{lst:devicespec}
        ,bytesMemory :: Int
        }
 \end{lstlisting}
        ,bytesMemory :: Int
        }
 \end{lstlisting}

+
+\subsection{Memory Management}

 \todo{Explain specification, combine task and share space}
 
 \subsection{Communication}
 \todo{Explain specification, combine task and share space}
 
 \subsection{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
+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
+       }
+
+class MTaskDuplex a where
+       synFun :: a (Shared Channels) -> Task ()
+\end{lstlisting}