2 Systems built with support for
\gls{mTask
} are often following the same design
3 pattern. First the devices are created --- with or without the interaction of
4 the user --- and they are then connected. When all devices are registered, the
5 \gls{mTask
}-
\glspl{Task
} can be sent and
\gls{iTasks
}-
\glspl{Task
} can be
6 started to monitor the output. When everything is finished, the devices are
7 removed and the system is shut down.
9 \begin{lstlisting
}[language=Clean,label=
{lst:framework
},
10 caption=
{\gls{mTask
} framework for building applications
}]
12 w = makeDevice "dev1" (...) >>= connectDevice
13 >>=
\dev1->makeDevice "dev2" (...) >>= connectDevice
16 >>*
[OnAction (Action "Shutdown") $ always
17 $ deleteDevice dev1 >>| deleteDevice dev2
23 \subsection{Thermostat
}
24 The thermostat is a classic example program for showing interactions between
25 peripherals. The following program shows a system containing two devices. The
26 first device --- the sensor --- contains a temperature sensor that measures the
27 room temperature. The second device --- the actor --- contains a heater,
28 connected to the digital pin
\CI{D5
}. Moreover, this device contains a led to
29 indicate whether the heater is on. The following code shows an implementation
30 for this. The code fully uses the framework. Note that a little bit of type
31 twiddling is required to fully us the result from the
\gls{SDS
}. This approach
32 is still type safe due to the type safety of
\CI{Dynamic
}s.
34 \begin{lstlisting
}[caption=
{Thermostat example
}]
36 thermos = makeDevice "nodeM" nodeMCU >>= connectDevice
37 >>=
\nod-> makeDevice "stm32" stm32 >>= connectDevice
38 >>=
\stm-> sendTaskToDevice "sensing" sensing (nod, OnInterval
1000)
39 >>= \(st,
[t
])->sendTaskToDevice "acting" acting (stm, OnInterval
1000)
40 (\(BCValue s)->set (BCValue $ dynInt (dynamic s) >
0) (shareShare nod a))
43 dynInt :: Dynamic -> Int
46 sensing = sds
\x=
0 In
{main=
47 x =. analogRead A0 :. pub x
49 acting = sds
\cool=False In
{main=
50 IF cool (ledOn LED1) (ledOff LED1) :.
56 \subsection[Lifting mTasks to iTasks-Tasks
]%
57 {Lifting
\gls{mTask
}-
\glspl{Task
} to
\gls{iTasks
}-
\glspl{Task
}}
58 If the user does not want to know where and when a
\gls{mTask
} is actually
59 executed and is just interested in the results it can lift the
\gls{mTask
} to
60 an
\gls{iTasks
}-
\gls{Task
}. The function is called with a name,
\gls{mTask
},
61 device and interval specification and it will return a
\gls{Task
} that finishes
62 if and only if the
\gls{mTask
} has returned.
64 \begin{lstlisting
}[caption=
{Lifting
\gls{mTask
}-
\glspl{Task
} to
\gls{iTasks
}}]
65 liftmTask :: String (Main (ByteCode () Stmt)) (MTaskDevice, MTaskInterval) -> Task
[MTaskShare
]
66 liftmTask wta mTask c=:(dev, _)= sendTaskToDevice wta mTask c
67 >>= \(t, shs)->wait "Waiting for mTask to return" (taskRemoved t) (deviceShare dev)
68 >>| viewInformation "Done!"
[] ()
71 taskRemoved t d = isNothing $ find (
\t1->t1.ident==t.ident) d.deviceTasks
74 The factorial function example from Chapter~
\ref{chp:mtaskcont
} can then be
75 lifted to a real
\gls{iTasks
}-
\gls{mTask
} with the following code:
76 \begin{lstlisting
}[caption=
{Lifting the factorial
\gls{Task
} to
\gls{iTasks
}}]
77 factorial :: MTaskDevice -> Task BCValue
78 factorial dev = enterInformation "Factorial of ?"
[]
79 >>=
\fac->liftmTask "fact" (fact fac) (dev, OnInterval
100)
80 @ fromJust o find (
\x->x.humanName == "result")
81 @
\s->s.MTaskShare.value
84 In namedsds
\x=(
1 Named "result")
85 In
{main = IF (y <=. lit
1)
87 ( x =. x *. y :. y =. y -. lit
1 )
}
90 \subsection{Heartbeat \& Oxygen Saturation Sensor
}
91 As an example, the addition of a new sensor will be demonstrated. The heartbeat
92 and oxygen saturation sensor add-on is a
\textsc{PCB
} the size of a fingernail
93 with a red
\gls{LED
} and a light sensor on it. Moreover, it contains an
94 \textsc{I2C
} chip to communicate. The company producing the chip provides the
95 programmer with example code for
\gls{Arduino
} and
\textsc{mbed
}. The sensor
96 emits red light and measures the returning light intensity. The microcontroller
97 hosting the device has to keep track of four seconds of samples to determine
98 the heartbeat. In the
\gls{mTask
}-system, an abstraction is made. The current
99 implementation runs on
\textsc{mbed
} supported devices.
101 \subsubsection{\gls{mTask
} Classes
}
102 First, a class has to be devised to store the functionality of the sensor. The
103 heartbeat sensor updates four values continuously, namely the heartbeat, the
104 validity of the reading, the oxygen saturation and the validity of it. For
105 every value a function is added to the new
\CI{hb
} class. Moreover, the
106 introduced datatype housing the values should implement the
\CI{mTaskType
}
107 classes. The definition is as follows:
109 \begin{lstlisting
}[caption=
{The
\texttt{hb
} class
}]
110 :: Heartbeat = HB Int
113 instance toByteCode Heartbeat, SP02
114 instance fromByteCode Heartbeat, SP02
115 derive class iTask Heartbeat, SP02
118 getHb :: (v Heartbeat Expr)
119 validHb :: (v Bool Expr)
120 getSp02 :: (v SP02 Expr)
121 validSp02 :: (v Bool Expr)
124 \subsubsection{Bytecode Implementation
}
125 The class is available now, and the implementation can be created. The
126 implementation is trivial since the functionality is limited to retrieving
127 single values and no assignment is possible. The following code shows the
128 implementation. Dedicated bytecode instructions have been added to support the
131 \begin{lstlisting
}[caption=
{The
\texttt{hb
} bytecode instance
}]
141 instance hb ByteCode where
142 getHb = tell`
[BCGetHB
]
143 validHb = tell`
[BCValidHB
]
144 getSp02 = tell`
[BCGetSP02
]
145 validSp02 = tell`
[BCValidSP02
]
148 \subsubsection{Device Interface
}
149 The bytecode instructions are added but still the functionality needs to be
150 added to the device interface to be implemented by clients. The following
151 addition to
\CI{interface.h
} and the interpreter shows the added instructions.
153 \begin{lstlisting
}[caption=
{Adding the device interface
}]
166 switch(program
[pc++
])
{
170 stack
[sp++
] = get_hb();
173 stack
[sp++
] = valid_hb();
176 stack
[sp++
] = get_spo2();
179 stack
[sp++
] = valid_spo2();
185 \subsubsection{Client Software
}
186 The device client software always executes the
\CI{real
\_setup} in which the
187 client software can setup the connection and peripherals. In the case of the
188 heartbeat peripheral it starts a thread running the calculations. The thread
189 started in the setup will set the global heartbeat and oxygen level variables
190 so that the interface functions for it can access it. The code is then as
193 \begin{lstlisting
}[language=C,caption=
{}]
197 void heartbeat_thread(void)
{
198 // Constant heartbeat calculations
201 void real_setup(void)
{
203 thread.start(heartbeat_thread);
207 \subsubsection{Example Program
}