X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=methods.arch.tex;h=cd9918dc81f0503bed43c06e4257c04e8425a983;hb=c701de5fbdb875ad9c2257f6fb54ebc8f7805d77;hp=9f41e56f7fc0be1f8ae899e39b4244bfa40aaff5;hpb=130cec648788a4660c91ffed6c1c2fb682413055;p=msc-thesis1617.git

diff --git a/methods.arch.tex b/methods.arch.tex
index 9f41e56..cd9918d 100644
--- a/methods.arch.tex
+++ b/methods.arch.tex
@@ -5,21 +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
-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.
 
-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}
-	\item $^*$\texttt{NIX} systems such as Linux
-	\item \emph{STM32} like development boards supported by \texttt{ChibiOS}
-		such as the \emph{STM32f7x} series.
-	\item \emph{Arduino} compatible microcontrollers. Even development boards
-		with as little as \emph{2K} \emph{RAM} such as the \emph{Arduino UNO}
-		are supported.
+	\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}
@@ -27,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
-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}}]
@@ -40,6 +50,38 @@ exact specification is listed in Listing~\ref{lst:devicespec}
 	,bytesMemory :: Int
 	}
 \end{lstlisting}
+
+\subsection{Memory Management}
 \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}