intro.related.tex

   1 Similar research has been conducted on the subject.
   2 For example, microcontrollers such as the \gls{Arduino} can be remotely
   3 controlled very directly using the
   4 \gls{Firmata}-protocol\footnote{``firmata/protocol: Documentation of the
   5 Firmata protocol.'' (\url{https://github.com/firmata/protocol}). [Accessed:
   6 23-May-2017].}. This protocol is designed to allow control of the peripherals
   7 --- such as sensors and actuators --- directly through commands sent via a
   8 communication channel such as a serial port.  This allows very fine grained
   9 control but with the cost of excessive communication overhead since no code is
  10 executed on the device itself, only the peripherals are queried. A
  11 \gls{Haskell} implementation of the protocol is also
  12 available\footnote{``hArduino by LeventErkok.'' (
  13 \url{https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}. The
  14 hardware requirements for running a \gls{Firmata} client are very low.
  15 However, the communication requirements are high and therefore it is not
  16 suitable for \gls{IoT} applications that operate through specialized \gls{IoT}
  17 networks which often only support low bandwidth.
  18
  19 \Gls{Clean} has a history of interpretation and there is a lot of research
  20 happening on the intermediate language \gls{SAPL}. \Gls{SAPL} is a purely
  21 functional intermediate language that is designed to be interpreted. It has
  22 interpreters written in \gls{C++}~\cite{jansen_efficient_2007} and
  23 \gls{Javascript}~\cite{domoszlai_implementing_2011}. Compiler backends exist
  24 for and \gls{Clean} and \gls{Haskell} which compile the respective code to
  25 \gls{SAPL}~\cite{domoszlai_compiling_2012}. The \gls{SAPL} language is still a
  26 functional language and therefore requires big stacks and heaps to operate and
  27 is therefore not directly suitable for devices with little RAM such as the
  28 \gls{Arduino}~Uno which only boasts $2K$ of RAM. It might be possible to
  29 compile the \gls{SAPL} code into efficient machine language or \gls{C} but then
  30 the system would lose its dynamic properties since the microcontroller then
  31 would have to be reprogrammed every time a new \gls{Task} is sent to the
  32 device.
  33
  34 \Glspl{EDSL} have often been used to generate \gls{C} code for microcontroller
  35 environments. This work uses parts of the existing \gls{mTask}-\gls{EDSL} which
  36 generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers%
  37 ~\cite{plasmeijer_shallow_2016}~\cite{koopman_type-safe_nodate}. Again, this
  38 requires a reprogramming cycle every time the \gls{Task}-specification is
  39 changed. Hence, the \gls{EDSL} is used but the backend is not suitable for the
  40 purpose of dynamic \gls{IoT} solutions.
  41
  42 Another \gls{EDSL} designed to generate low-level high-assurance programs is
  43 called \gls{Ivory} and uses \gls{Haskell} as a host language%
  44 ~\cite{elliott_guilt_2015}. The language uses the \gls{Haskell} type-system to
  45 make unsafe languages type safe. For example, \gls{Ivory} has been used in the
  46 automotive industry to program parts of an autopilot%
  47 ~\cite{pike_programming_2014}~\cite{hickey_building_2014}. \Gls{Ivory}'s syntax
  48 is deeply embedded but the type system is shallowly embedded. This requires
  49 several \gls{Haskell} extensions that offer dependent type constructions. The
  50 process of compiling an \gls{Ivory} program happens in two stages. The embedded
  51 code is transformed into an \gls{AST} that is sent to a chosen backend. The
  52 technique used in the novel system using the \gls{mTask}-\gls{EDSL} is
  53 different, in the new system, the \gls{EDSL} is transformed directly into
  54 functions. There is no intermediate \gls{AST}. Moreover, \gls{Ivory} generates
  55 static programs and thus it is necessary to reprogram the devices when they
  56 need to be repurposed. It would be interesting to explore the possibilities of
  57 writing the client software in an \gls{EDSL} as well.
  58
  59 Not all \gls{IoT} devices run solely compiled code. The popular \emph{ESP8266}
  60 powered \textsc{NodeMCU} is able to run interpreted \gls{LUA} code. Moreover,
  61 there is a variation on \gls{Python} called \emph{micropython} that is suitable
  62 for running on microcontrollers. However, the overhead of the interpreter for
  63 such rich languages often results into limitations on the program size. It
  64 would not be possible to repurpose a device with \gls{IoT} because implementing
  65 this extensibility in the interpreted language leaves no room for the actual
  66 programs. Also, some devices only have $2K$ of ram, which is not enough for
  67 this.