--- /dev/null
+@incollection{achten_introduction_2015,
+ title = {An {Introduction} to {Task} {Oriented} {Programming}},
+ booktitle = {Central {European} {Functional} {Programming} {School}},
+ publisher = {Springer},
+ author = {Achten, Peter and Koopman, Pieter and Plasmeijer, Rinus},
+ year = {2015},
+ pages = {187--245},
+}
+@unpublished{koopman_tasks_2016,
+ title = {Tasks in a {Type}-{Safe} and {Extendible} {Domain} {Specific} {Language} for {Microprocessors}},
+ author = {Koopman, Pieter and Plasmeijers, Rinus},
+ year = {2016},
+ note = {Draft paper},
+ file = {tfp16.pdf:/home/mrl/.mozilla/firefox/spscjqzf.default/zotero/storage/9DCKVX3V/tfp16.pdf:application/pdf}
+}
--- /dev/null
+%&a
+\begin{document}
+\maketitleru[
+ course={Research Intership},
+ righttextheader={Supervisors:},
+ righttext={P.W.M. Koopman\\M.J. Plasmeijers}]
+
+\section{Introduction}
+In \emph{Task Oriented Programming} (TOP) a program is built out of pieces of
+work called \emph{tasks}~\cite{achten_introduction_2015}. Tasks differ from
+function in the way that they return a result. A task's return value can change
+over time. Task exist in many forms and they can be composed sequentially and
+in parallel. Some possible tasks are asking for user input via a web browser,
+setting up a TCP connection to another server or combining several tasks. At
+the moment there are several types of leaf tasks. A leaf task is a task that
+does not consist of tasks itself. Examples of leaf tasks are the so called
+editors.
+
+This paper describes the effort to add another type of leaf task that
+focusses on microcontrollers. Microcontrollers are often not powerful
+enough to run a full-fledged task server and therefore there is the need to
+introduce special microcontroller tasks. Effort for this is already made by by
+the department~\cite{koopman_tasks_2016}. However, communication between the
+\emph{mTask} and the iTasks system is still lacking and exactly that will be the
+goal of the project. This requires adding a new type of leaf task that allows
+the user to run \emph{mTasks} on microcontrollers. The leaf task should
+abstract away from communication techniques and it should be relatively easy to
+add techniques. Techniques that are interesting to experiment with is Serial
+communication, Bluetooth, \textsc{WiFi}, \textsc{GSM} and \textsc{LoRa}.
+
+\section{mTasks}
+The current implementation of \emph{mTask}s can be used to generate \emph{C}
+code that will run a mini-taskserver on a microcontroller. This project will
+strip the original \emph{mTask} of this functionality and embed communication
+in the system.
+
+\section{Microcontroller}
+Every microcontroller will run the \emph{mTask-engine}. This engine is a
+program that has two jobs. The first job of the engine is to listen to the
+\iTasks{} server to which it is connected via one of the aforementioned
+methods. The \iTasks{} server can send task specifications and SDS
+specifications to the engine to process.
+
+The second job of the engine is to run the tasks in a round robin fashion.
+Every task has a frequency of execution and when the task want a turn he will
+be executed by the engine through interpreting the bytecode. Tasks can change
+SDS's and therefore the engine also has to keep the \iTasks{} server updated
+with the changes. The specifics of this are explained in detail later on.
+
+\section{Communication}
+We can divide the communication up into two parts. Communication from the
+\iTasks{} server to the microcontroller and vice versa. The means of
+communicating are unimportant, this can be TCP, Serial or any other
+communication method that sends data in a linear way.
+
+\subsection{\iTasks{} $\rightarrow$ microcontroller}
+
+
+\subsection{Microcontroller $\rightarrow$ \iTasks{}}
+The only thing the microcontroller has to communicate back with the server is
+an update of the SDS and a request for an SDS value.
+Since all SDS's have a numeric identifier the engine can just send a request
+message with the identifier to the server. A detailed description of the
+message is described in Table~\ref{tbl:sdssend}.
+
+\begin{table}[H]
+ \centering
+ \begin{tabular}{ll}
+ \toprule
+ Bytes & Description\\
+ \midrule
+ $1$ & SDS send code \verb#'s'#\\
+ $2-5$ & SDS identifier as a 16-bit integer\\
+ $2-5$ & Length of the message 16-bit integer\\
+ $n$ & Value of the SDS identifier\\
+ \bottomrule
+ \end{tabular}
+ \caption{Message format for a SDS-send operation}\label{tbl:sdssend}
+\end{table}
+
+\section{Improvements and future research}
+In the current implementation the number of possible tasks that can run
+simultaneously is fixed. A future project can implement dynamic task allocation
+and garbage collection that is then needed. Since memory is scarce on a
+microcontroller the program can not go and \verb#malloc# all the time to
+allocate new memory on the heap for the tasks. Over time this will cause
+fragmentation and eventually the program will run out of memory. A solution for
+this could be to let the engine handle the memory management and reorder and
+defragment the tasks on demand.
+
+Another improvement could be the task scheduling. At the moment all tasks get
+one slice in which they are executed as a whole. Because of this the use of
+loops is not possible since a loop will block the entire program. A possible
+solution for this is to give different stack and program pointers to each task
+and save them separately. In this way the interpreter can slice the programs
+and pause one to let another run and through this it will be possible to add
+loops to the DSL and make the DSL even more imperative like.
+
+\bibliographystyle{ieeetr}
+\bibliography{a}
+\end{document}
--- /dev/null
+% Radboud University Nijmegen titlepage
+% Author: Mart Lubbers
+% Date: 2016-11-15
+\RequirePackage{geometry,graphicx,ifpdf,keyval,iflang}
+
+\def\@rutitleauthors{\@author}
+\def\@rutitlepagenr{\thepage}
+\define@key{maketitleru}{course}{\def\@rutitlecourse{#1}}
+\define@key{maketitleru}{institute}{\def\@rutitleinst{#1}}
+\define@key{maketitleru}{authorstext}{\def\@rutitleauthorstext{#1}}
+\define@key{maketitleru}{authors}{\def\@rutitleauthors{#1}}
+\define@key{maketitleru}{righttext}{\def\@rutitlerighttext{#1}}
+\define@key{maketitleru}{righttextheader}{\def\@rutitlerighttextheader{#1}}
+\define@key{maketitleru}{righttextB}{\def\@rutitlerighttextb{#1}}
+\define@key{maketitleru}{righttextBheader}{\def\@rutitlerighttextbheader{#1}}
+\define@key{maketitleru}{pagenr}{\def\@rutitlepagenr{#1}}
+\setkeys{maketitleru}{%
+ course={},
+ institute={Radboud Universit\IfLanguageName{dutch}{eit}{y} Nijmegen},
+ authorstext={\IfLanguageName{dutch}{Auteurs: }{Authors:}},
+ righttextheader={},
+ righttext={}
+}
+\newcommand{\maketitleru}[1][]{
+ \setkeys{maketitleru}{#1}
+ \newgeometry{hmarginratio=1:1}
+ \begin{titlepage}
+ \setcounter{page}{\@rutitlepagenr}
+ \begin{center}
+ \textsc{\LARGE\@rutitlecourse}\\[1.5cm]
+ \ifpdf\includegraphics[height=150pt]{logo.pdf}\\
+ \else\includegraphics[height=150pt]{logo.eps}\\
+ \fi
+ \vspace{0.4cm}
+ \textsc{\Large\@rutitleinst}\\[1cm]
+ \hrule
+ \vspace{0.4cm}
+ \textbf{\large\@title}\\[0.4cm]
+ \hrule
+ \vspace{2cm}
+ \begin{minipage}[t]{0.45\textwidth}
+ \begin{flushleft}\large
+ \textit{\@rutitleauthorstext}\\
+ \@rutitleauthors{}
+ \end{flushleft}
+ \end{minipage}
+ \begin{minipage}[t]{0.45\textwidth}
+ \begin{flushright}\large
+ \textit{\@rutitlerighttextheader}\\
+ \@rutitlerighttext%
+ \end{flushright}
+ \end{minipage}
+
+ \vspace{1cm}
+ \ifdefined\@rutitlerighttextb
+ \begin{minipage}[t]{0.45\textwidth}
+ ~
+ \end{minipage}
+ \begin{minipage}[t]{0.45\textwidth}
+ \begin{flushright}\large
+ \textit{\@rutitlerighttextbheader}\\
+ \@rutitlerighttextb%
+ \end{flushright}
+ \end{minipage}
+ \fi
+ \vfill
+ {\large\@date}
+ \end{center}
+ \end{titlepage}
+ \restoregeometry
+}
repositories / ri1617.git / commitdiff