From: Mart Lubbers Date: Mon, 26 Jun 2017 10:47:54 +0000 (+0200) Subject: roy's comments: chapter 5 X-Git-Tag: hand-in~50 X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=2cc098c4bb590b3493bd20b37fe24a70b0407625;p=msc-thesis1617.git roy's comments: chapter 5 --- diff --git a/results.arch.tex b/results.arch.tex index e4e5d38..e9db688 100644 --- a/results.arch.tex +++ b/results.arch.tex @@ -5,9 +5,9 @@ bytecode by the \gls{mTask}-view --- to the device. The device runs an interpreter which can execute the \gls{Task}'s bytecode. Device profiles should be persistent during reboots of the \gls{iTasks}-system. The methods of interacting with \glspl{mTask} should be analogous to interacting with -\gls{iTasks}-\glspl{Task}. Meaning that programmers can access the \glspl{SDS} -made for a device in the same way as a regular \gls{SDS} and they can execute -\glspl{mTask} as if it where a normal \gls{iTasks}-\gls{Task}. +\gls{iTasks}-\glspl{Task}. This means that programmers can access the +\glspl{SDS} made for a device in the same way as a regular \gls{SDS} and they +can execute \glspl{mTask} as if it where a normal \gls{iTasks}-\gls{Task}. The following terms will be used throughout the following chapter: \begin{itemize} @@ -42,8 +42,8 @@ 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 +implement all type classes in the \gls{EDSL}. When the device connects with +the server for the first time, the specifications of what is implemented is communicated. At the time of writing the following device families are supported and can run @@ -57,7 +57,7 @@ the device software. This is tested in particular on the \texttt{STM32f7x} series \gls{ARM} development board. - \item Microcontrollers who are programmable in the \gls{Arduino} \gls{IDE} + \item Microcontrollers that are programmable in the \gls{Arduino} \gls{IDE} connected via serial communication or via \gls{TCP} over WiFi. This does not only include \gls{Arduino} compatible boards but also @@ -65,9 +65,9 @@ the device software. client has been made for the \texttt{ESP8266} powered \emph{NodeMCU} that is connected via \gls{TCP} over WiFi. A port also has been made for the regular \gls{Arduino} \emph{UNO} board which only boasts a - meager \emph{2K} of \emph{RAM}. The stack size and storage for such - small amount of \emph{RAM} have to be smaller than default but it still - suitable to hold a hand full of \glspl{Task}. + meager \emph{2K} \emph{RAM}. The stack size and storage available for + devices boasting this little \emph{RAM} has to be smaller than default + but is still suitable to hold a hand full of \glspl{Task}. \end{itemize} \subsection{Client} @@ -121,10 +121,10 @@ all \glspl{Task} are relocated in the memory space to not leave holes. Both memory space, helper functions are available to loop through them without having to fiddle in the memory space itself. The instance for \glspl{Task} and \glspl{SDS} are shown in Listing~\ref{lst:structs} accompanied by the helper -functions for \glspl{Task}. \Glspl{Task} consist the length, interval, last run -time, id and the bytecode. \Glspl{SDS} consist just of an id, value and type. -The pointer to the bytecode of the \gls{Task} always points to the location in -the memory space. +functions for \glspl{Task}. \Glspl{Task} consists of the length, interval, last +run time, id and the bytecode. \Glspl{SDS} consist only of an id, value and +type. The pointer to the bytecode of the \gls{Task} always points to the +location in the memory space. \begin{lstlisting}[language=C,label={lst:structs},% caption={The data type storing the \glspl{Task}}] @@ -154,12 +154,12 @@ The execution of a \gls{Task} is started by running the \CI{run\_task} function and always start with prepared the stack and the program counter and stack pointer are set to zero and the bottom respectively. When finished, the interpreter executes one step at the time while the program counter is smaller -than the program length. The code for this is listed in -Listing~\ref{lst:interpr}. One execution step is basically a big switch -statement going over all possible bytecode instructions. Some instructions are -detailed upon in the listing. The \CI{BCPush} instruction is a little more -complicated in the real code because some decoding will take place as not all -\CI{BCValue}s are of the same length and are encoded. +than the program length. This code is listed in Listing~\ref{lst:interpr}. One +execution step is basically a big switch statement going over all possible +bytecode instructions. Some instructions are detailed upon in the listing. The +\CI{BCPush} instruction is a little more complicated in the real code because +some decoding will take place as not all \CI{BCValue}s are of the same length +and are encoded. \begin{lstlisting}[language=C,label={lst:interpr},% caption={Rough code outline for interpretation}] @@ -266,8 +266,8 @@ 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 +channels. To send a message to the device, the system 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 @@ -285,31 +285,31 @@ format are explained in the following section. The architecture of the system keeps track of the \glspl{SDS} stored on the client in a big \gls{SDS} containing a list of devices. Client-\glspl{SDS} can be stored on one device at the same time. This means that if a \gls{SDS} -updates, everyone watching it will be notified. This would result in to a lot -of notifications that are not meant for the listener. Moreover, when a client +updates, everyone watching it will be notified. This would result in a lot +of notifications that are not meant for the watcher. Moreover, when a client updates the \gls{SDS} this is processed by the connection handler and results in an update of the real \gls{SDS}. Finally, the \gls{SDS} of a client must be synchronized with the actual device. Thus, when an \gls{iTasks}-\gls{Task} writes the client-\gls{SDS}, it must be propagated to the real device. There -are several ways of tackling this problem each with their own pros and cons and +are several ways of tackling this problem, each with their own pros and cons and their own level of abstraction. First an actual \gls{iTasks}-\gls{SDS} for every \gls{SDS} used in a client can be instantiated with one \gls{iTasks}-\gls{Task} listening to the \gls{SDS} and -synchronizing it with the device when an update occured. This approach is very +synchronizing it with the device when an update occurred. This approach is very expensive as it requires a lot of listening \glspl{Task}. Improved on this, a single \gls{iTasks}-\gls{SDS} can be created for every devices that stores the respective \glspl{SDS}. Using the \CI{mapReadWrite} functions, a single \gls{SDS} per device can be created as a lens that allows -mapping on a single client-\gls{SDS}. However, This approach still requires +mapping on a single client-\gls{SDS}. However, this approach still requires \glspl{Task} listening to the \gls{SDS} and when a \gls{SDS} is written, -everyone is notified, even if the \gls{Task} wanted to only watch a single +everyone is notified, even if the \gls{Task} only uses the value of a single different \gls{SDS}. Ultimately, the current approach --- a single \gls{SDS} for the entire system --- was explored. To create \glspl{SDS} per device or per client-\glspl{SDS} a -\CI{mapReadWrite} can be used but it suffers the same problem as mentioned +\CI{mapReadWrite} can be used but it suffers from the same problem as mentioned before. Moreover, a \gls{Task} still has to watch the \gls{SDS} and communicate the client-\gls{SDS} updates to the actual device. Both of these problems can be solved by using a tailor made share that heavily depends on parametric @@ -427,12 +427,12 @@ where The communication from the server to the client and vice versa is just a character stream containing encoded \gls{mTask} messages. The \CI{synFun} belonging to the device is responsible for sending the content in the left -channel and putting received messages in the right channel. Moreover, it should -set the boolean value to \CI{True} when the connection is terminated. The +channel and putting received messages in the right channel. Moreover, the +boolean value should be set to \CI{True} when the connection is terminated. The specific encoding of the messages is visible in -Appendix~\ref{app:communication-protocol}. The type holding the messages in -Listing~\ref{lst:avmsg}. Detailed explanation about the message types and -according actions will be given in the following subsections. +Appendix~\ref{app:communication-protocol}. The type holding the messages is +shown in Listing~\ref{lst:avmsg}. Detailed explanation about the message types +and according actions will be given in the following subsections. \begin{lstlisting}[label={lst:avmsg},caption={Available messages}] :: MTaskId :== Int @@ -459,8 +459,8 @@ channels, starts the synchronization \gls{Task} (\CI{synFun}), makes sure the errors are handled when needed and runs a processing function in parallel to react on the incoming messages. Moreover, it sends a specification request to the device in question to determine the details of the device and updates the -record to contain the top-level \gls{Task}-id. All the device functionality -heavily depends on the specific \CI{deviceShare} function that generates a +record to contain the top-level \gls{Task}-id. All device functionality +heavily depends on the specific \CI{deviceShare} function that generates an \gls{SDS} for a specific device. This allows giving an old device record to the function and still update the latest instance. Listing~\ref{lst:connectDevice} shows the connection function. @@ -514,15 +514,14 @@ diagram is shown in Figure~\ref{fig:tasksend}. 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 \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}. -After waiting for the acknowledgement the device is updated again and the -\gls{Task} returns. +The new \glspl{SDS} that were generated during compilation are merged with the +existing device's \glspl{SDS}. Furthermore the messages are placed in the +channel \gls{SDS} 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}. After waiting for the acknowledgement the device is +updated again and the \gls{Task} returns. \begin{lstlisting}[label={lst:sendtask},% caption={Sending a \gls{Task} to a device}] @@ -550,9 +549,9 @@ where \end{lstlisting} \subsection{Miscellaneous Messages} -There exists one special type of message that is sent to the device only when +One special type of message is available which is sent to the device only when it needs to reboot. When the server wants to stop the bond with the device it -sends the \CI{MTShutdown} message. The device will then clear his memory, thus +sends the \CI{MTShutdown} message. The device will then clear its memory, thus losing all the \glspl{SDS} and \glspl{Task} that were stored and reset itself. Shortly after the shutdown message a new server can connect to the device because the device is back in listening mode. @@ -575,8 +574,8 @@ called \CI{mTaskManager}. To manage the system, a couple of different functionalities are needed and are launched. An image of the management interface is shown in Figure~\ref{lst:manage}. The left sidebar of the interface shows the list of example \glspl{Task} that are present in the -system. When clicking a \gls{Task}, a dialog opens in which you can select the -device to send the \gls{Task} to. The dialog might contain user specified +system. When clicking a \gls{Task}, a dialog opens in which a device can be +selected to send the \gls{Task} to. The dialog might contain user specified variables. All example \glspl{mTask} are of the type \CI{Task (Main (ByteCode () Stmt))} and can thus ask for user input first if needed for parameterized \glspl{mTask}. The bottom panel shows the device information. In this panel, diff --git a/thesis.pre b/thesis.pre index 493ff0e..afdb732 100644 --- a/thesis.pre +++ b/thesis.pre @@ -116,6 +116,8 @@ language=Clean } +\setcounter{secnumdepth}{5} + \title{Task Oriented Programming and the Internet of Things} \author{Mart Lubbers BSc.\\ {\small\href{mailto:mart@martlubbers.net}{mart@martlubbers.net}}}