process camil's comments
[msc-thesis1617.git] / arch.example.tex
index 828e097..ad8c4db 100644 (file)
@@ -1,5 +1,5 @@
 \subsection{Framework}
-Systems built with support for \gls{mTask} are often following the same design
+Systems built with support for \gls{mTask} often follow the same design
 pattern. First the devices are created --- with or without the interaction of
 the user --- and they are then connected. When all devices are registered, the
 \gls{mTask}-\glspl{Task} can be sent and \gls{iTasks}-\glspl{Task} can be
@@ -25,11 +25,12 @@ The thermostat is a classic example program for showing interactions between
 peripherals. The following program shows a system containing two devices. The
 first device --- the sensor --- contains a temperature sensor that measures the
 room temperature. The second device --- the actor --- contains a heater,
-connected to the digital pin \CI{D5}. Moreover, this device contains a led to
-indicate whether the heater is on. The following code shows an implementation
-for this. The code fully uses the framework. Note that a little bit of type
-twiddling is required to fully us the result from the \gls{SDS}. This approach
-is still type safe due to the type safety of \CI{Dynamic}s.
+connected to the digital pin \CI{D5}. Moreover, this device contains an
+\gls{LED} to indicate whether the heater is on. The following code shows an
+implementation for this. The code makes use of all the aspects of the
+framework. Note that a little bit of type twiddling is required to fully use
+the result from the \gls{SDS}. This approach is still type safe due to the type
+safety of \CI{Dynamic}s.
 
 \begin{lstlisting}[caption={Thermostat example}]
 thermos :: Task ()
@@ -55,8 +56,8 @@ where
 
 \subsection[Lifting mTasks to iTasks-Tasks]%
        {Lifting \gls{mTask}-\glspl{Task} to \gls{iTasks}-\glspl{Task}}
-If the user does not want to know where and when a \gls{mTask} is actually
-executed and is just interested in the results it can lift the \gls{mTask} to
+If the user does not want to know where and when an \gls{mTask} is actually
+executed and is just interested in the results, it can lift the \gls{mTask} to
 an \gls{iTasks}-\gls{Task}. The function is called with a name, \gls{mTask},
 device and interval specification and it will return a \gls{Task} that finishes
 if and only if the \gls{mTask} has returned.
@@ -72,7 +73,7 @@ where
 \end{lstlisting}
 
 The factorial function example from Chapter~\ref{chp:mtaskcont} can then be
-lifted to a real \gls{iTasks}-\gls{mTask} with the following code:
+lifted to a real \gls{iTasks}-\gls{Task} with the following code:
 \begin{lstlisting}[caption={Lifting the factorial \gls{Task} to \gls{iTasks}}]
 factorial :: MTaskDevice -> Task BCValue
 factorial dev = enterInformation "Factorial of ?" []
@@ -92,19 +93,19 @@ As an example, the addition of a new sensor will be demonstrated. The heartbeat
 and oxygen saturation sensor add-on is a \textsc{PCB} the size of a fingernail
 with a red \gls{LED} and a light sensor on it. Moreover, it contains an
 \textsc{I2C} chip to communicate. The company producing the chip provides the
-programmer with example code for \gls{Arduino} and \textsc{mbed}. The sensor
-emits red light and measures the returning light intensity. The microcontroller
-hosting the device has to keep track of four seconds of samples to determine
-the heartbeat. In the \gls{mTask}-system, an abstraction is made. The current
-implementation runs on \textsc{mbed} supported devices.
+programmer with example code for \gls{Arduino} and \gls{mbed}. The sensor
+emits red light and measures the intensity of the light returned. The
+microcontroller hosting the device has to keep track of four seconds of samples
+to determine the heartbeat. In the \gls{mTask}-system, an abstraction is made.
+The current implementation runs on \gls{mbed} supported devices.
 
 \subsubsection{\gls{mTask} Classes}
 First, a class has to be devised to store the functionality of the sensor. The
 heartbeat sensor updates four values continuously, namely the heartbeat, the
-validity of the reading, the oxygen saturation and the validity of it. For
-every value a function is added to the new \CI{hb} class. Moreover, the
-introduced datatype housing the values should implement the \CI{mTaskType}
-classes. The definition is as follows:
+oxygen saturation and the validity of the two. For every value a function is
+added to the new \CI{hb} class. Moreover, the introduced datatype housing the
+values should implement the \CI{mTaskType} classes. The definition is as
+follows:
 
 \begin{lstlisting}[caption={The \texttt{hb} class}]
 :: Heartbeat = HB Int