\begin{document}
\maketitleru[authorstext={Author:},
course={Research Intership},
+ subtitle={Final review},
righttextheader={Supervisors:},
- righttext={M.J.~Plasmeijer\\P.W.M.~Koopman}]
+ 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
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}]
+\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
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}]
+\begin{lstlisting}[language=Clean,label={lst:mtask},
+ caption={Parts of the mTask DSL}]
:: Upd = Upd
:: Expr = Expr
:: Stmt = Stmt
\subsection{Devices}
For the devices an engine has been built that can receive mTasks and SDSs and
-execute them accordingly
+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?
%
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}}.
+\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 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.
+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
%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.
+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 be the foundation for my thesis.
+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)
repositories / ri1617.git / commitdiff