methods.tex

   1 \section{\acrlong{TOP}}
   2 \gls{TOP} is a recent new programming paradigm implemented as
   3 \gls{iTasks}~\cite{achten_introduction_2015} in
   4 the pure lazy functional language \gls{Clean}
   5
   6 \todo{Main terms}
   7 The lazy functional programming language based on graph rewriting
   8 \gls{Clean}~\cite{brus_cleanlanguage_1987}
   9
  10 \section{\acrlong{EDSL}s}
  11 \glspl{mTask} are expressed in a class based shallowly embedded \gls{EDSL}.
  12 There are two main types of \glspl{EDSL}.
  13 \todo{Small shallow embedded dsl intro}
  14 \todo{Small deep embedded dsl}
  15 \todo{Show that class based has the best of both worlds}
  16
  17 \section{Devices}
  18 The client code for the devices is compiled from one codebase. For a device to
  19 be eligible for \glspl{mTask} it must be able to compile the shared codebase
  20 and implement (part of) the device specific interface. The shared codebase only
  21 uses standard \gls{C} and no special libraries or tricks are used. Therefore
  22 the code is compilable for almost any device or system. Note that it is not
  23 needed to implement a full interface\todo{handshake}. The full interface,
  24 listed in Appendix~\label{app:device-interface}, also includes functions for
  25 accessing the peripherals that not every device might have.
  26
  27 \subsection{Specification}
  28 Devices are stored in a record type and all devices in the system are stored in
  29 a \gls{SDS} containing all devices.
  30
  31 \subsection{Communication}
  32
  33
  34 \section{mTasks}
  35 \subsection{\gls{EDSL}}
  36
  37 \subsection{Shares}
  38 %\subsection{Serial port communication in Clean and iTasks}
  39 %In the first exploration stage I added duplex serial port communication to
  40 %iTasks in the same way as TCP is added. To make it work several changes had to
  41 %be done to the iTasks core to allow backgroundtasks to be added at runtime. The
  42 %function shown in Listing~\ref{lst:serialtask} results into a task that
  43 %sends the data added to the output queue through the serial port and adds data
  44 %received to the input queue for the user to process.
  45 %
  46 %\begin{lstlisting}[caption={Serial port communication in iTasks},
  47 %       language=Clean,label={lst:serialtask}]
  48 %syncSerialChannel :: String TTYSettings (Shared ([String],[String],Bool)) -> Task ()
  49 %
  50 %:: ByteSize = BytesizeFive | BytesizeSix | BytesizeSeven | BytesizeEight
  51 %:: Parity = ParityNone | ...ParityOdd | ParityEven | ParitySpace | ParityMark
  52 %:: BaudRate = ... | B9600 | B19200 | ...
  53 %:: TTYSettings = {
  54 %       baudrate :: BaudRate,
  55 %       bytesize :: ByteSize,
  56 %       parity :: Parity,
  57 %       stop2bits :: Bool,
  58 %       xonxoff :: Bool}
  59 %\end{lstlisting}
  60 %
  61 %\subsection{mTasks}
  62 %The core of the project revolves around the embedded domain specific language
  63 %(EDSL) called mTask designed by Pieter Koopman. mTasks is used to use the task
  64 %oriented programming on microcontrollers in a type-safe environment. Originally
  65 %mTasks are compiled to c code that could be compiled for arduino compatible
  66 %devices.  Such generated code will be flashed to the program memory once. In
  67 %short, the original mTask system is comparable to an entire iTasks sytem
  68 %including the engine.
  69 %
  70 %For this project the imperative language constructs of the mTask DSL are used.
  71 %Listing~\ref{lst:mtask} shows some of these class base DSL components for
  72 %things like arithmetics, sequencing, conditionals, shared data sources and
  73 %interaction with the user LEDs. Together with some helper functions code
  74 %programmed in this DSL can be compiled to bytecode and sent to a device.
  75 %
  76 %\begin{lstlisting}[language=Clean,label={lst:mtask},
  77 %       caption={Parts of the mTask DSL}]
  78 %:: Upd   = Upd
  79 %:: Expr  = Expr
  80 %:: Stmt  = Stmt
  81 %:: UserLED = LED1 | LED2 | LED3
  82 %
  83 %:: Main a = {main :: a}
  84 %
  85 %class arith v where
  86 %  lit :: t -> v t Expr | ...
  87 %  (+.) infixl 6 :: (v t p) (v t q) -> v t Expr | ...
  88 %class IF v where
  89 %  IF :: (v Bool p) (v t q) (v s r) -> v () Stmt | isExpr p
  90 %class sds v where
  91 %  sds :: ((v t Upd)->In t (Main (v c s))) -> (Main (v c s)) | ...
  92 %  pub :: (v t Upd) -> v t Expr | ...
  93 %class seq v where
  94 %  (:.) infixr 0 :: (v t p) (v u q) -> v u Stmt | ...
  95 %class assign v where
  96 %  (=.) infixr 2 :: (v t Upd) (v t p) -> v t Expr | ...
  97 %class noOp v where noOp :: v t p
  98 %class userLed v where
  99 %       ledOn :: UserLED -> (v () Stmt)
 100 %       ledOff :: UserLED -> (v () Stmt)
 101 %\end{lstlisting}
 102 %
 103 %\subsection{iTasks}
 104 %In iTasks several tasks have been devised to handle the communication. Moreover
 105 %the tasks will synchronize the shared data sources in the mTask domain with
 106 %real SDSs in the iTasks domain allowing for communication between mTasks and
 107 %iTasks tasks. To not clutter the communication channels the SDSs are not
 108 %synchronized on every change on the device. When a share changes on the server
 109 %his new value will be pushed to the device immediately. When a share is updated
 110 %on the client it must be explicitly published using. This approach has been
 111 %taken because some shares might be only used internally and therefore would
 112 %clutter the communication channels that could be low-bandwidth.
 113 %
 114 %
 115 %\subsection{Devices}
 116 %For the devices an engine has been built that can receive mTasks and SDSs and
 117 %execute them accordingly. To add a new device to the list the programmer just
 118 %has to implement a relatively small interface. All the other functionality is
 119 %using standard C or the interface. This interface is listed in~%
 120 %\ref{lst:interface} and includes reading and writing data, controlling the
 121 %peripherals and some auxiliary functions.
 122 %
 123 %\begin{lstlisting}[language=c,caption={Device interface},label={lst:interface}]
 124 %uint8_t read_byte(void);
 125 %void write_byte(uint8_t b);
 126 %
 127 %void write_dpin(uint8_t i, bool b);
 128 %bool read_dpin(uint8_t i);
 129 %
 130 %void write_apin(uint8_t i, uint8_t a);
 131 %uint8_t read_apin(uint8_t i);
 132 %
 133 %long millis(void);
 134 %bool input_available(void);
 135 %void delay(long ms);
 136 %
 137 %void setup(void);
 138 %void debug(char *fmt, ...);
 139 %void pdie(char *s);
 140 %void die(char *fmt, ...);
 141 %\end{lstlisting}
 142 %
 143 %mTasks run either at a fixed interval or are one-shot which is added to the
 144 %message. The entire protocol specification can be found in the code that is
 145 %available. When an mTask is one-shot it will only be executed once and then
 146 %removed. This can be useful for user related tasks such as shutting down blinds
 147 %or turning on lights for an indefinite time. mTasks that run at a fixed
 148 %interval time can be used to monitor sensors or to periodically communicate
 149 %with peripherals like LCD screens.
 150 %
 151 %There are many things to be improved upon in future research. Most likely these
 152 %points will be touched upon in my Master's thesis research.
 153 %\begin{itemize}
 154 %       \item Support task combinators and functions.
 155 %
 156 %               The mTask language already supports the step combinator and it might be
 157 %               fruitful to add for more expressively. Moreover functions would also
 158 %               add a lot. They can be used to share code between tasks to reduce the
 159 %               bytecode size.
 160 %       \item Seamless integration with iTasks.
 161 %
 162 %               At the moment everything works but is hacked together. I would like to
 163 %               extend this with a more robust system that allows adding devices on the
 164 %               fly and adds functionality to monitor the mTask devices.
 165 %       \item Dynamic mTask/SDS allocation.
 166 %
 167 %               Currently all client data for mTask and SDS storage is statically
 168 %               allocated. This means that when only a few tasks are used the memory
 169 %               needed is too high. This can be improved upon by only allocating
 170 %               resources for tasks when they are requested and this would allow the
 171 %               system to run on low memory devices like arduino's.
 172 %       \item Extend on SDSs.
 173 %
 174 %               In the current system the shared data sources used in mTask programs
 175 %               live in a different domain and are synchronized with an iTask
 176 %               counterpart. Programming mTasks could be made more intuitive if you
 177 %               could use standard SDSs from iTasks. Moreover, at the moment only
 178 %               integer and boolean shares are allowed. This really should be extended
 179 %               to at least strings.
 180 %       \item Slicing tasks.
 181 %
 182 %               Every mTask runs in its entirety and to not run into race and
 183 %               scheduling problems loops are not allowed in the mTasks. An improvement
 184 %               to this could be multithreading the tasks by giving them slices of
 185 %               computation and pausing them every slice. In this way loops could be
 186 %               allowed without blocking the entire system. It does require more memory
 187 %               however.
 188 %       \item Run tasks when an interrupt fires.
 189 %
 190 %               Tasks can be scheduled either one-shot or at an interval. It might be
 191 %               useful to tie mTasks to hardware interrupts to increase responsiveness
 192 %               and possibly battery life. These interrupts do not need to be hardware
 193 %               based. A usecase might be to run a task when some other task is
 194 %               yielding a value (see task combinators) or to run a task when a shared
 195 %               data source is received from the server.
 196 %\end{itemize}