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}
\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}
repositories / msc-thesis1617.git / commitdiff