update frontpage and finalize report"

[ri1617.git] / final_review / a.tex

%&a
\begin{document}
\maketitleru[authorstext={Author:},
        course={Research Intership},
        subtitle={Final review},
        righttextheader={Supervisors:},
        righttext={prof.~dr.~dr.h.c.~ir~M.J.~Plasmeijer\\dr.~P.W.M.~Koopman}]

\section{Activities}
% Activities Describe which activities you have carried our, incl. how you have
% documented or recorded your work. 
The internship started with exploring the possibilities of adding embedded
devices that are typical to the internet of things (IoT) to the iTasks
framework. A lot of communication in the IoT goes via low-powered low-bandwidth
networks to ensure maximum battery life. Moreover the devices often have little
memory and little processing power for the same reasons. Therefore such devices
can not run an entire iTasks system.

Communication with these devices must be simple and energy and processing power
limited. Much of the communication goes via simple serial connections and
therefore the first practical problem to tackle was to add this communication
type to Clean and iTasks.

In the last stage I have created an application that can send on the fly
compiled bytecode to embedded devices to run imperative tasks called mTasks
using sensor, actuators and communicate data via shares.

\subsection{Serial port communication in Clean and iTasks}
In the first exploration stage I added duplex serial port communication to
iTasks in the same way as TCP is added. To make it work several changes had to
be done to the iTasks core to allow backgroundtasks to be added at runtime. The
function shown in Listing~\ref{lst:serialtask} results into a task that
sends the data added to the output queue through the serial port and adds data
received to the input queue for the user to process.

\begin{lstlisting}[caption={Serial port communication in iTasks},
        language=Clean,label={lst:serialtask}]
syncSerialChannel :: String TTYSettings (Shared ([String],[String],Bool)) -> Task ()

:: ByteSize = BytesizeFive | BytesizeSix | BytesizeSeven | BytesizeEight
:: Parity = ParityNone | ...ParityOdd | ParityEven | ParitySpace | ParityMark
:: BaudRate = ... | B9600 | B19200 | ...
:: TTYSettings = {
        baudrate :: BaudRate,
        bytesize :: ByteSize,
        parity :: Parity,
        stop2bits :: Bool,
        xonxoff :: Bool}
\end{lstlisting}

\subsection{mTasks}
The core of the project revolves around the embedded domain specific language
(EDSL) called mTask designed by Pieter Koopman. mTasks is used to use the task
oriented programming on microcontrollers in a type-safe environment. Originally
mTasks are compiled to c code that could be compiled for arduino compatible
devices.  Such generated code will be flashed to the program memory once. In
short, the original mTask system is comparable to an entire iTasks sytem
including the engine.

For this project the imperative language constructs of the mTask DSL are used.
Listing~\ref{lst:mtask} shows some of these class base DSL components for
things like arithmetics, sequencing, conditionals, shared data sources and
interaction with the user LEDs. Together with some helper functions code
programmed in this DSL can be compiled to bytecode and sent to a device.

\begin{lstlisting}[language=Clean,label={lst:mtask},
        caption={Parts of the mTask DSL}]
:: Upd   = Upd
:: Expr  = Expr
:: Stmt  = Stmt
:: UserLED = LED1 | LED2 | LED3

:: Main a = {main :: a}

class arith v where
  lit :: t -> v t Expr | ...
  (+.) infixl 6 :: (v t p) (v t q) -> v t Expr | ...
class IF v where
  IF :: (v Bool p) (v t q) (v s r) -> v () Stmt | isExpr p
class sds v where
  sds :: ((v t Upd)->In t (Main (v c s))) -> (Main (v c s)) | ...
  pub :: (v t Upd) -> v t Expr | ...
class seq v where
  (:.) infixr 0 :: (v t p) (v u q) -> v u Stmt | ...
class assign v where
  (=.) infixr 2 :: (v t Upd) (v t p) -> v t Expr | ...
class noOp v where noOp :: v t p
class userLed v where
        ledOn :: UserLED -> (v () Stmt)
        ledOff :: UserLED -> (v () Stmt)
\end{lstlisting}

\subsection{iTasks}
In iTasks several tasks have been devised to handle the communication. Moreover
the tasks will synchronize the shared data sources in the mTask domain with
real SDSs in the iTasks domain allowing for communication between mTasks and
iTasks tasks. To not clutter the communication channels the SDSs are not
synchronized on every change on the device. When a share changes on the server
his new value will be pushed to the device immediately. When a share is updated
on the client it must be explicitly published using. This approach has been
taken because some shares might be only used internally and therefore would
clutter the communication channels that could be low-bandwidth.


\subsection{Devices}
For the devices an engine has been built that can receive mTasks and SDSs and
execute them accordingly. To add a new device to the list the programmer just
has to implement a relatively small interface. All the other functionality is
using standard C or the interface. This interface is listed in~%
\ref{lst:interface} and includes reading and writing data, controlling the
peripherals and some auxiliary functions.

\begin{lstlisting}[language=c,caption={Device interface},label={lst:interface}]
uint8_t read_byte(void);
void write_byte(uint8_t b);

void write_dpin(uint8_t i, bool b);
bool read_dpin(uint8_t i);

void write_apin(uint8_t i, uint8_t a);
uint8_t read_apin(uint8_t i);

long millis(void);
bool input_available(void);
void delay(long ms);

void setup(void);
void debug(char *fmt, ...);
void pdie(char *s);
void die(char *fmt, ...);
\end{lstlisting}

mTasks run either at a fixed interval or are one-shot which is added to the
message. The entire protocol specification can be found in the code that is
available. When an mTask is one-shot it will only be executed once and then
removed. This can be useful for user related tasks such as shutting down blinds
or turning on lights for an indefinite time. mTasks that run at a fixed
interval time can be used to monitor sensors or to periodically communicate
with peripherals like LCD screens.

\section{Results}
% Results What were the results and contributions? How did you document these?
% 
% Only give a very brief description of the outcome of the research. Where
% possible give pointers to places where more can be found about this. E.g. if
% you have produced or contributed to software, data sets, articles, technical
% reports, or other forms of documentation, then give pointers to these, but
% don't include all this in this final report.
The overall results are very promising and are to be continued in the Master's
thesis. The foundations have been laid out to make a seamless ecosystem that
allows small devices to interact with iTasks programs and the other way
around.

All code is available on the university's gitlab website. The serial port
library written for clean can be found here~%
\footnote{\url{https://gitlab.science.ru.nl/mlubbers/CleanSerial}}.
All mTask code can be found here~%
\footnote{\url{https://gitlab.science.ru.nl/mlubbers/mTask}}. This repository
is also the main documentation for the code. While some parts of the
architecture have been documented in the following repository, this will be the
main source.
All source code for the reports and presentations can be found here~%
\footnote{\url{https://git.martlubbers.net/?p=ri1617.git;a=summary}}.

There are many things to be improved upon in future research. Most likely these
points will be touched upon in my Master's thesis research.
\begin{itemize}
        \item Support task combinators and functions.

                The mTask language already supports the step combinator and it might be
                fruitful to add for more expressively. Moreover functions would also
                add a lot. They can be used to share code between tasks to reduce the
                bytecode size.
        \item Seamless integration with iTasks.

                At the moment everything works but is hacked together. I would like to
                extend this with a more robust system that allows adding devices on the
                fly and adds functionality to monitor the mTask devices.
        \item Dynamic mTask/SDS allocation.

                Currently all client data for mTask and SDS storage is statically
                allocated. This means that when only a few tasks are used the memory
                needed is too high. This can be improved upon by only allocating
                resources for tasks when they are requested and this would allow the
                system to run on low memory devices like arduino's.
        \item Extend on SDSs.

                In the current system the shared data sources used in mTask programs
                live in a different domain and are synchronized with an iTask
                counterpart. Programming mTasks could be made more intuitive if you
                could use standard SDSs from iTasks. Moreover, at the moment only
                integer and boolean shares are allowed. This really should be extended
                to at least strings.
        \item Slicing tasks.

                Every mTask runs in its entirety and to not run into race and
                scheduling problems loops are not allowed in the mTasks. An improvement
                to this could be multithreading the tasks by giving them slices of
                computation and pausing them every slice. In this way loops could be
                allowed without blocking the entire system. It does require more memory
                however.
        \item Run tasks when an interrupt fires.

                Tasks can be scheduled either one-shot or at an interval. It might be
                useful to tie mTasks to hardware interrupts to increase responsiveness
                and possibly battery life. These interrupts do not need to be hardware
                based. A usecase might be to run a task when some other task is
                yielding a value (see task combinators) or to run a task when a shared
                data source is received from the server.
\end{itemize}

\section{Reflection \& Evaluation}
%Don't just evaluate and reflect on your results, but also on what you've done
%to get there.
The results are positive, however the process was far from seamless. At several
points in time the hardware was causing a lot of problems that required a lot
of intensive debugging and redoing a lot of work in different frameworks. It
would have been much worse if these struggles took place in the Master's Thesis
project. However, I could spend enough time to fix the issues because the focus
of a research internship is not to answer discreet research questions. It could
also be supporting work or very exploratory research. The final presentation of
the internship also went very well in my idea. It brought new and interesting
ideas for the future. The presentation was held in a meeting for iTasks users
to notify eachother of the research that is going on in the topic.

%What went well/not so well/(not) according to plan?  What was harder/easier
%than expected? (Either due to the subject matter, or your skills and
%experience.) Are there particular activities that you found hard or easy, or
%that you are not (or not yet) good at? If you were to start over on the
%internship, what would you do differently?
I would have done some things a little different. At one point in the
internship it was not clear for the supervisors what I was doing. While we had
weekly meetings there were no clear milestones and deliverables every week. We
solved this by producing a support document that introduced the architecture.
This document was never finished but could serve as a base of my thesis and
cleared things up for the supervisors. In the future I would take more care in
having agreements like that to force myself to work in more discreet steps and
plan more ahead.

Regarding the research matters itself I was unpleasantly surprised how much
time went in getting the basics up and running. Hardware is a pain to debug and
it took some iterations to get a stable system. However, this time is well
spent because it will most likely be part of the foundations for my thesis.

%Look ahead to your Master thesis, and to your future career: also given your
%experiences in the research intership, what kind of research would you (not)
%like to do for your Master thesis?  Would you want to do your Master thesis
%internally at the university or at an external organisation? What are topics,
%skills, or activities that you want to work at during your Master thesis or
%your future career? Are there topics or activities that you want to avoid in
%the future? Or that you would to specialise in your future career? 
For my master's thesis I am very happy that the days of debugging hardware are
over and that I can focus on the interesting bits. When the foundations are
strong enough that you can trust the abstraction layers the real fun starts. My
dream is to get my doctorate and continue working in the academic as a teacher
and researcher. This internship strengthened this dream and therefore I will
continue to aspire it.
\end{document}