\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
+
+
+
\section{Results}
% Results What were the results and contributions? How did you document these?
% 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}}.
+All source code for the reports and presentations can be found here~%
+\footnote{\url{https://git.martlubbers.net/?p=ri1617.git;a=summary}}.
\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 varying
+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 was not purely on answering research questions and could also
+be supporting work. The final presentation of the internship also went very
+well. It gave fresh ideas for the following thesis that was very usable.
%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. 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 be the foundation 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)
%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}