--- /dev/null
+In the \emph{Arduino} ecosystem, shields are available to plug into the
+microcontroller and add functionality. These shields range from Bluetooth,
+WiFi, Ethernet, LoRa, LCD screens and much more. Often the functionality
+available in these shields is housed in a \gls{C++} class. This functionality
+is ported using little work to \gls{mTask} by just creating a corresponding
+class with the same functions. As an example, Listing~\ref{lst:lcd} shows parts
+of the \gls{LCD} class as an \gls{mTask} class functions and as
+Listing~\ref{lst:lcdc} shown the corresponding \emph{Arduino} class functions.
+
+\begin{lstlisting}[label={lst:lcd},%
+ caption={Adding the \gls{LCD} to the \gls{mTask} language}]
+:: LCD = ...
+
+class lcd v where
+ begin :: (v LCD Expr) (v Int p) (v Int q) -> v () Expr
+ LCD :: Int Int [DigitalPin] ((v LCD Expr) -> Main (v b q)) -> Main (v b q)
+ ...
+ scrollLeft :: (v LCD Expr) -> v () Expr
+ scrollRight :: (v LCD Expr) -> v () Expr
+ ...
+\end{lstlisting}
+
+\begin{lstlisting}[language=C++,label={lst:lcdc},%
+ caption={Functions from the \gls{Arduino} \gls{LCD} library}]
+class LiquidCrystal {
+public:
+ void begin(uint8_t cols, uint8_t rows);
+ ...
+ void scrollDisplayLeft();
+ void scrollDisplayRight();
+ ...
+}
+\end{lstlisting}
Some example \gls{mTask}-\glspl{Task} --- using almost all of their
-functionality --- are shown in Listing~\ref{lst:exmtask}. The
-\gls{mTask}-\glspl{Task} shown in the example do not belong to a particular
-view and therefore are of the type \CI{View t r}. The \CI{blink} \gls{mTask}
-show the classic \gls{Arduino} blinking \gls{LED} application that blinks a
-certain \gls{LED} every second. The \CI{thermostat} expression will enable a
-digital pin powering a cooling fan when the analog pin representing a
-temperature sensor is too high. \CI{thermostat`} shows the same expression but
+functionality --- are shown in Listing~\ref{lst:exmtask}. The \CI{blink}
+\gls{mTask} show the classic \gls{Arduino} blinking \gls{LED} application that
+blinks a certain \gls{LED} every second. The \CI{thermostat} expression will
+enable a digital pin powering a cooling fan when the analog pin representing a
+temperature sensor is too high. \CI{thermostat`} shows the same expression but
now using the assignment style \gls{GPIO} technique. The \CI{thermostat}
example also shows that it is not necessary to run everything as a \CI{task}.
The main program code can also just consist of the contents of the root
-\CI{main} itself.
+\CI{main} itself. Finally a thermostat example is shown that also displays the
+temperature on its \gls{LCD} while regulating the temperature.
\begin{lstlisting}[%
label={lst:exmtask},caption={Some example \gls{mTask}-\glspl{Task}}]
-blink = task \blink=(\x.
+a0 = aIO A0
+d0 = dIO D0
+
+blink = task \blink.(\x.
IF (x ==. lit True) (ledOn led) (ledOff led) :.
blink (lit 1000) (Not x)
In {main=blink (lit 1000) True}
-thermostat :: Main (View () Stmt)
thermostat = {main = digitalWrite D0 (analogRead A0 >. lit 50) }
-thermostat` :: Main (View () Stmt)
-thermostat` = let
- a0 = aIO A0
- d0 = dIO D0 in {main = d0 =. a0 > lit 50 }
+thermostat` = {main = d0 =. a0 > lit 50 }
+
+thermostat`` = task \th.(\lcd.
+ d0 =. a0 > lit 50 :.
+ print lcd a0 :.
+ th (lit 1000) lim ) In
+ LCD 16 12 [] \lcd.{main = th (lit 1000) lim }
\end{lstlisting}
\begin{lstlisting}[%
label={lst:sdsio},caption={Input/Output classes}]
:: DigitalPin = D0 | D1 | D2 | D3 | D4 | D5 |D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13
-:: AnalogPin = A0 | A1 | A2 | A3 | A4 | A5
+:: AnalogPin = A0 | A1 | A2 | A3 | A4 | A5
:: UserLED = LED1 | LED2 | LED3
class dIO v where dIO :: DigitalPin -> v Bool Upd
class aIO v where aIO :: AnalogPin -> v Int Upd
class analogRead v where
- analogRead :: AnalogPin -> v Int Expr
- analogWrite :: AnalogPin (v Int p) -> v Int Expr
+ analogRead :: AnalogPin -> v Int Expr
+ analogWrite :: AnalogPin (v Int p) -> v Int Expr
class digitalRead v where
- digitalRead :: DigitalPin -> v Bin Expr
- digitalWrite :: DigitalPin (v Bool p) -> v Int Expr
+ digitalRead :: DigitalPin -> v Bin Expr
+ digitalWrite :: DigitalPin (v Bool p) -> v Int Expr
:: UserLED = LED1 | LED2 | LED3
class userLed v where
- ledOn :: (v UserLED q) -> (v () Stmt)
- ledOff :: (v UserLED q) -> (v () Stmt)
+ ledOn :: (v UserLED q) -> (v () Stmt)
+ ledOff :: (v UserLED q) -> (v () Stmt)
class assign v where
- (=.) infixr 2 :: (v t Upd) (v t p) -> v t Expr | ...
+ (=.) infixr 2 :: (v t Upd) (v t p) -> v t Expr | ...
\end{lstlisting}
One way of storing data in \gls{mTask}-\glspl{Task} is using \glspl{SDS}.
-\glspl{SDS} serve as variables in \gls{mTask} and maintain their value across
-executions. \glspl{SDS} can be used by multiple \glspl{Task} and can be used
-to share data. The classes associated with \glspl{SDS} are listed in
+\glspl{SDS} serve as global variables in \gls{mTask} and maintain their value
+across executions. \glspl{SDS} can be used by multiple \glspl{Task} and can be
+used to share data. The classes associated with \glspl{SDS} are listed in
Listing~\ref{lst:sdsclass}. The \CI{Main} type is introduced to box an
\gls{mTask} and make it recognizable by the type system by separating programs
-and decorations such as \glspl{SDS}.
+and decorations such as \glspl{SDS}. The type signature is complex and uses
+infix type constructors and therefore, an implementation example is also given.
\begin{lstlisting}[%
label={lst:sdsclass},caption={\glspl{SDS} in \gls{mTask}}]
:: Main a = {main :: a}
class sds v where
- sds :: ((v t Upd)->In t (Main (v c s))) -> (Main (v c s)) | ...
-\end{lstlisting}
-
-In the \emph{Arduino} ecosystem, shields are available to plug into the
-microcontroller and add functionality. These shields range from Bluetooth,
-WiFi, Ethernet, LoRa, LCD screens and much more. Often the functionality
-available in these shields is housed in a \gls{C++} class. This functionality
-is ported using little work to \gls{mTask} by just creating a corresponding
-class with the same functions. As an example, Listing~\ref{lst:lcd} shows parts
-of the \gls{LCD} class as an \gls{mTask} class functions and as
-Listing~\ref{lst:lcdc} shown the corresponding \emph{Arduino} class functions.
-
-\begin{lstlisting}[label={lst:lcd},%
- caption={Adding the \gls{LCD} to the \gls{mTask} language}]
-:: LCD = ...
-
-class lcd v where
- begin :: (v LCD Expr) (v Int p) (v Int q) -> v () Expr
- ...
- scrollLeft :: (v LCD Expr) -> v () Expr
- scrollRight :: (v LCD Expr) -> v () Expr
- ...
-\end{lstlisting}
+ sds :: ((v t Upd) -> In t (Main (v c s))) -> (Main (v c s)) | ...
-\begin{lstlisting}[language=C++,label={lst:lcdc},%
- caption={Functions from the \gls{Arduino} \gls{LCD} library}]
-class LiquidCrystal {
-public:
- void begin(uint8_t cols, uint8_t rows);
- ...
- void scrollDisplayLeft();
- void scrollDisplayRight();
- ...
-}
+sdsExample :: Main (v Int Stmt)
+sdsExample = sds \x.0 In
+ {main= x =. x +. lit 42 }
\end{lstlisting}
The \gls{C}-backend of the \gls{mTask}-system has an engine that is generated
alongside the code for the \glspl{Task}. This engine will execute the
-\gls{mTask}-\glspl{Task} according to certain rules and semantics.
+\gls{mTask}-\glspl{Task} according to certain rules and execution strategies.
\gls{mTask}-\glspl{Task} do not behave like functions but more like
\gls{iTasks}-\glspl{Task}. An \gls{mTask} is queued when either its timer runs
out or when it is launched by another \gls{mTask}. When an \gls{mTask} is
actual \gls{Task} will be executed anytime in the future.
The \gls{iTasks}-backend simulates the \gls{C}-backend and thus uses the same
-semantics. This engine expressed in pseudocode is listed as
+scheduling strategy. This engine expressed in pseudocode is listed as
Algorithm~\ref{lst:engine}. All the \glspl{Task} are inspected on their waiting
time. When the waiting time has not passed; the delta is subtracted and the
\gls{Task} gets pushed to the end of the queue. When the waiting has surpassed
class mtask v a where
task :: (((v delay r) a->v MTask Expr)->In (a->v u p) (Main (v t q))) -> Main (v t q) | ...
-count = task \count = (\n.count (lit 1000) (n +. One)) In {main = count (lit 1000) Zero}
+count = task \count = (\n.count (lit 1000) (n +. lit 1)) In
+ {main = count (lit 1000) (lit 0)}
\end{lstlisting}
variables\footnote{kind \CI{*->*->*}.} that implements some of the classes
given. The types do not have to be present as fields in the view and can, and
will most often, be exclusively phantom types. Thus, views are of the
-form:\\\CI{:: v t r = ...}. The first type variable will be the type of the
+form: \CI{:: v t r = ...}. The first type variable will be the type of the
view. The second type variable will be the type of the \gls{EDSL}-expression
and the third type variable represents the role of the expression. Currently
the role of the expressions form a hierarchy. The three roles and their
hierarchy are shown in Listing~\ref{lst:exprhier}. This implies that everything
is a statement, only an \CI{Upd} and an \CI{Expr} are expressions. The \CI{Upd}
restriction describes updatable expressions such as \gls{GPIO} pins and
-\glspl{SDS}.
+\glspl{SDS}. The roles are used to constrain certain classes. For example,
+without the roles for \CI{Upd}. Assignment would be possible to a
+non-assignable expression such as a literal integer.
\begin{lstlisting}[%
label={lst:exprhier},caption={Expression role hierarchy}]
\section{Control flow}
\input{mtask.control}
-\section{Input/Output and Class Extensions}
+\section{Input/Output}
\input{mtask.io}
-\section{Semantics}
-\input{mtask.semantics}
+\section{Class Extensions}
+\input{mtask.class}
+
+\section{Scheduling Strategy}
+\input{mtask.scheduling}
\section{Example mTask}
\input{mtask.examples}
intro: Problem statement en introductie uitwijden
-mtask: edsl, uitleggen waarom die hierarchie nodig is, isExpr
-mtask: voorbeelde sds
mtask: semantics anders noemen
emtsk: semantics, anders noemen en voorbeelden geven in strategies
emtsk: Voorbeeldje voor namedsds
repositories / msc-thesis1617.git / commitdiff