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