-The goal of the total system is to facilitate an ecosystem in which an
-\gls{iTasks}-system can add, change and remove devices at runtime. Moreover,
-the \gls{iTasks}-system can send \glspl{mTask} --- compiled at runtime to
-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
+The goal of the system as a whole is to offer a framework of functions with
+which an \gls{iTasks}-system can add, change and remove devices at runtime.
+Moreover, the \gls{iTasks}-system can send \glspl{mTask} --- compiled at
+runtime to 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}. 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}.
+\glspl{SDS} made for a device in the same way as regular \glspl{SDS} and they
+can execute \gls{mTask}-\glspl{Task} as if they where normal
+\gls{iTasks}-\glspl{Task}.
The following terms will be used throughout the following chapter:
\begin{itemize}
\item Device, Client
- This denotes the actual device connected to the system. This can be a
+ These terms denotes the actual device connected to the system. This can be a
real device such as a microcontroller but it can also just be a program
on the same machine as the server functioning as a client.
\item Server, \gls{iTasks}-System
At the time of writing the following device families are supported and can run
the device software.
\begin{itemize}
- \item \texttt{POSIX} compatible systems connected via \gls{TCP}.
+ \item \texttt{POSIX} compatible systems connected via the \gls{TCP}.
This includes systems running \emph{Linux} and \emph{MacOS}.
- \item \texttt{STM32} family microcontrollers supported by \texttt{ChibiOS}
- connected via serial communication.
+ \item The \texttt{STM32} microcontrollers family supported by
+ \texttt{ChibiOS} connected via serial communication.
This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
development board.
- \item Microcontrollers that are programmable in the \gls{Arduino} \gls{IDE}
- connected via serial communication or via \gls{TCP} over WiFi.
+ \item Microcontrollers which are programmable in the \gls{Arduino} \gls{IDE}
+ connected via serial communication or via \gls{TCP} over WiFi or
+ ethernet.
This does not only include \gls{Arduino} compatible boards but also
other boards capable of running \gls{Arduino} code. A port of the
for the regular \gls{Arduino} \emph{UNO} board which only boasts a
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}.
+ but are still suitable to hold a hand full of \glspl{Task}.
\end{itemize}
\subsection{Client}
$t\leftarrow \text{now}()$\;
\ForEach{$t\leftarrow tasks$}{
- \uIf{is\_interrupt$(t) \&\& $had\_interrupt$(t)$}{
+ \uIf{is\_interrupt$(t)$ \textbf{and} had\_interrupt$(t)$}{
run\_task$(t)$\;
}
\ElseIf{$t-t.\text{lastrun} > t.\text{interval}$}{
dynamically allocated but that would require using the heap which is unwanted
in small memory environments. \Glspl{Task} grow from the bottom up and
\glspl{SDS} grow from the top down. When a \gls{Task} or \gls{SDS} is removed,
-all \glspl{Task} are relocated in the memory space to not leave holes. Both
-\glspl{Task} and \glspl{SDS} are stored as structures that are linked in the
-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} 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.
+all \glspl{Task} residing in higher areas of the memory are relocated in the
+memory space to not leave holes. Both \glspl{Task} and \glspl{SDS} are stored
+as structures that are linked in the memory space, helper functions are
+available to loop through them without having to fiddle in the memory space
+itself. The instances for \glspl{Task} and \glspl{SDS} are shown in
+Listing~\ref{lst:structs} accompanied by the helper 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}}]
\subsubsection{Interpretation}
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
+and always starts with setting the program counter and stack
+pointer 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. 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.
+bytecode instructions. Of some instructions, the implementations are shown 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}]
From the macro settings in the interface file, a profile is created that
describes the specification of the device. When the 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
+specification. The client serializes its specification and send it to the
server so that the server knows what the client is capable of. The exact
specification is shown in Listing~\ref{lst:devicespec} and stores the
peripheral availability, the memory available for storing \glspl{Task} and
\section{iTasks}
The server part of the system is written in \gls{iTasks}. Functions for
managing devices, \glspl{Task} and \glspl{SDS} have been created to support the
-functionality. An interactive application has been created that allows an
+functionality. An interactive web application has been created that provides an
interactive management console for the \gls{mTask} system. This interface
-provides functionality to list \glspl{SDS}, add \glspl{Task}, remove
-\glspl{Task}, administrate devices and view the state of the system.
+provides functionality to list \glspl{SDS}, add and remove \glspl{Task},
+administrate devices and view the state of the system.
\subsection{Device Storage}
Everything that a device encompasses is stored in the \CI{MTaskDevice} record
format are explained in the following section.
\subsection{Shares}
-The architecture of the system keeps track of the \glspl{SDS} stored on
+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 a lot
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
-their own level of abstraction.
+are several ways of tackling this problem each with their own level of
+granularity.
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
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
+Finally, 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 from the same problem as mentioned
before. Moreover, a \gls{Task} still has to watch the \gls{SDS} and communicate
lenses.
\subsection{Parametric Lenses}
-The type of the parametric lens is \CI{Maybe (MTaskDevice, Int)}. The \gls{SDS}
-can be responsible for the entire list of devices, from now on global.
-Moreover, the \gls{SDS} can focus on a single device, from now on local. A
-local \gls{SDS} can also specifically focus on a single \gls{SDS} on a single
-device, from now on called local-share. The implementation of the real
-\gls{SDS} is given in Listing~\ref{lst:actualdev}. The \gls{SDS} is a lens on
-an actual \gls{SDS} that writes to a file or memory. Reading the \gls{SDS} is
-nothing more than reading the real \gls{SDS}. Writing the \gls{SDS} is a little
-bit more involved. If the write operation originated from a \gls{SDS} focussed
-on a single client-\gls{SDS}, the write action must also be relayed to the
-actual device. If the write originated from a \gls{SDS} focussed the devices or
-on one device only, nothing needs to be done. The notification predicate
-determines whether a watcher gets a notification update.
+The type for the parametric lens of the big \gls{SDS} is \CI{Maybe
+(MTaskDevice, Int)}. The \gls{SDS} is responsible for storing the entire list
+of devices, from now on global. Moreover, the \gls{SDS} can focus on a single
+device, from now on local. A local \gls{SDS} can also specifically focus on a
+single \gls{SDS} on a single device, from now on called local-share. The
+implementation of the real \gls{SDS} is given in Listing~\ref{lst:actualdev}.
+The \gls{SDS} is a lens on an actual \gls{SDS} that writes to a file or memory.
+Reading the \gls{SDS} is nothing more than reading the real \gls{SDS}. Writing
+the \gls{SDS} is a little bit more involved. If the write operation originated
+from a \gls{SDS} focussed on a single client-\gls{SDS}, the write action must
+also be relayed to the actual device. If the write originated from a \gls{SDS}
+focussed the devices or on one device only, nothing needs to be done. The
+notification predicate determines whether a watcher gets a notification update.
\begin{lstlisting}[label={lst:actualdev},%
caption={Device \gls{SDS}}]
The system's management is done through the interface of a single \gls{Task}
called \CI{mTaskManager}. To manage the system, a couple of different
-functionalities are needed and are launched. An image of the management
+functionalities are necessary 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 a device can be
repositories / msc-thesis1617.git / commitdiff