From 57dab117db1fa358785cc3992053206584df0b53 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Thu, 2 Mar 2017 20:22:54 +0100 Subject: [PATCH] big update --- abstract.tex | 2 +- appendix-protocol.tex | 4 +- introduction.tex | 9 +-- methods.tex | 164 +++++++++++++++++++++++++++++++++++++++++- thesis.tex | 4 +- 5 files changed, 171 insertions(+), 12 deletions(-) diff --git a/abstract.tex b/abstract.tex index 1272fab..aba9886 100644 --- a/abstract.tex +++ b/abstract.tex @@ -1,6 +1,6 @@ This thesis presents a way to connect small \gls{IoT} devices with high level \gls{TOP} implementations languages. It shows how a new frontend for the class -based shallowly embedded \glspl{DSL} called \gls{mTask} written in \gls{Clean} +based shallowly embedded \glspl{EDSL} called \gls{mTask} written in \gls{Clean} can be used to compile \gls{IoT}-tasks on the fly and send them to the device as bytecode which is interpreted. All of this adheres to the \gls{TOP} philosophy where familiar concepts such as \glspl{SDS} and task-combinators are diff --git a/appendix-protocol.tex b/appendix-protocol.tex index 4330283..4f1672d 100644 --- a/appendix-protocol.tex +++ b/appendix-protocol.tex @@ -20,7 +20,9 @@ the message is not acknowledged or responded upon. byte & value\\ \midrule 1 & \texttt{'t'}\\ - 2,3 & interval\\ + 2,3 & interval. If the first bit is 1 the other 15 indicate the + interrupt on which the task should be run. If the first bit is 0 + the other 15 indicate the interval in milliseconds\\ 4,5 & length (\texttt{n})\\ 6 to n+6 & bytecode\\ \midrule\midrule diff --git a/introduction.tex b/introduction.tex index 4352f6e..dd538b9 100644 --- a/introduction.tex +++ b/introduction.tex @@ -1,6 +1,6 @@ -\section{Motivation} +\section{Introduction} \Gls{TOP} and \gls{iTasks} have been designed to offer a high abstraction level -through a \gls{DSL} that describes workflows as \glspl{Task}. \gls{iTasks} has +through a \gls{EDSL} that describes workflows as \glspl{Task}. \gls{iTasks} has been shown to be useful in fields such as incident management~\cite{lijnse_top_2013}. However, there still lacks support for small devices to be added in the workflow. In principle such adapters can be written @@ -17,13 +17,10 @@ as small as Arduino microcontrollers and operates via the same paradigms as regular \glspl{Task}. The \glspl{mTask} have access to \glspl{SDS} and can run small imperative programs. -\section{Problem statement} -Therefore the problem statement is as follows: - \section{Document structure} The structure of the thesis is as follows. Chapter~\ref{chp:introduction} contains the problem statement, motivation and -the structure of the document +the structure of the document. Chapter~\ref{chp:methods} describes the foundations on which the implementation is built together with the new techniques introduced. Chapter~\ref{chp:results} shows the results in the form of an example diff --git a/methods.tex b/methods.tex index a4c9138..ae92075 100644 --- a/methods.tex +++ b/methods.tex @@ -7,7 +7,7 @@ the pure lazy functional language \gls{Clean} The lazy functional programming language based on graph rewriting \gls{Clean}~\cite{brus_cleanlanguage_1987} -\section{\acrlong{DSL}s} +\section{\acrlong{EDSL}s} \section{Devices} @@ -15,7 +15,167 @@ The lazy functional programming language based on graph rewriting \subsection{Communication} + \section{mTasks} -\subsection{\gls{DSL}} +\subsection{\gls{EDSL}} \subsection{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. +% +%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} diff --git a/thesis.tex b/thesis.tex index b447d2f..3a7477e 100644 --- a/thesis.tex +++ b/thesis.tex @@ -5,14 +5,14 @@ \newacronym{SDS}{SDS}{Shared Data Source} \newacronym{IoT}{IoT}{Internet of Things} \newacronym{TOP}{TOP}{Task Oriented Programming} -\newacronym{DSL}{DSL}{Design Specific Language} +\newacronym{EDSL}{(E)DSL}{(Embedded) Design Specific Language} \newacronym{RISC}{RISC}{Reduced Instruction Set Computer} \newacronym{ARM}{ARM}{Acorn \acrshort{RISC} Machine} \newglossaryentry{Clean}{name=Clean, description={is a pure lazy functional programming language based on graph rewriting}} \newglossaryentry{iTasks}{name=iTasks, - description={is a \acrshort{TOP} implementation written as a \acrshort{DSL} + description={is a \acrshort{TOP} implementation written as a \acrshort{EDSL} in the \gls{Clean} programming language}} \newglossaryentry{Task}{name=Task, description={is the basic building block of a \acrshort{TOP} system}} -- 2.20.1