}
\end{lstlisting}
+The code on the device generates the specification. When a device does not have
+a specific peripheral, the code will also not be on the device. In the
+interface file, the code for peripherals is always guarded by macros. Thus, if
+the peripheral is not there, the macro is set accordingly and the code will not
+be included. To illustrate this, Listings~\ref{lst:macro}-\ref{lst:macro3}
+show parts of the interface file and device specification generation function
+for the \emph{NodeMCU} microcontroller which only boasts a single analog pin
+and eight digital pins.
+
+\begin{minipage}{.49\textwidth}
+ \begin{lstlisting}[label={lst:macro},language=C,%
+ caption={Specification in the interface}]
+...
+#elif defined ARDUINO_ESP8266_NODEMCU
+#define APINS 1
+#define DPINS 8
+#define STACKSIZE 1024
+#define MEMSIZE 1024
+#define HAVELED 0
+#define HAVEHB 0
+
+#if APINS > 0
+void write_apin(uint8_t p, uint8_t v);
+uint8_t read_apin(uint8_t pin);
+#endif
+ \end{lstlisting}
+\end{minipage}
+\begin{minipage}{.49\textwidth}
+ \begin{lstlisting}[label={lst:macro3},language=C,%
+ caption={Actual generation}]
+...
+void spec_send(void) {
+ write_byte('c');
+ write_byte(0 | (HAVELED << 0)
+ | (HAVELCD << 1)
+ | (HAVEHB << 2)
+ | ...);
+ write16(MEMSIZE);
+ write16(STACKSIZE);
+ write_byte(APINS);
+ write_byte(DPINS);
+ write_byte('\n');
+}
+ \end{lstlisting}
+\end{minipage}
+
\subsection{Add a device}
A device can be added by filling in the \CI{MTaskDevice} record as much as
possible and running the \CI{connectDevice} function. This function grabs and
This is also tested in particular on the \texttt{STM32f7x} series
\gls{ARM} development board.
- \item Microcontrollers which are programmable in the \gls{Arduino} \gls{IDE}
- connected via serial communication or via \gls{TCP} over WiFi or
- Ethernet.
+ \item Microcontrollers which are programmable in the \gls{Arduino}
+ \gls{IDE} connected via serial communication or via \gls{TCP} over WiFi
+ or Ethernet.
This does not only include \gls{Arduino} compatible boards but also
other boards capable of running \gls{Arduino} code. A port of the
memory on the heap are not very space optimal and often leave holes in the heap
if allocations are not freed in a last in first out fashion. To overcome this
problem, the client will allocate a big memory segment in the global data
-block. This block of memory resides under the stack and its size can be set in
+block. This block of memory resides under the stack and its size can be set in
the interface implementation. This block of memory will be managed in a similar
way as the entire memory space of the device is managed. \Glspl{Task} will grow
from the bottom up and \glspl{SDS} will grow from the top down.
\section{Communication}\label{sec:communication}
\input{arch.communication}
-\section{Example}
+\section{Example}\label{sec:archexamples}
\input{arch.example}
--- /dev/null
+\Gls{mTask}-\glspl{SDS} on a client are available on the server as in the form
+of regular \gls{iTasks}-\glspl{SDS}. However, the same freedom that an
+\gls{SDS} has in the \gls{iTasks}-system is not given for \glspl{SDS} that
+reside on the client. Not all types are suitable to be located on a client,
+simply because it needs to be representable on clients and serializable for
+communication. Moreover, \glspl{SDS} behave a little different in an
+\gls{mTask} device compared to in the \gls{iTasks} system. In an \gls{iTasks}
+system, when the \gls{SDS} is updated, a broadcast to all watching \glspl{Task}
+in the system is made to notify them of the update. \glspl{SDS} can update
+often and the update might not be the final value it will get. Implementing the
+same functionality on the \gls{mTask} client would result in a lot of expensive
+unneeded bandwidth usage. Therefore a device must publish the \gls{SDS}
+explicitly to save bandwidth. Note that this means that the \gls{SDS} value on
+the device can be different compared to the value of the same \gls{SDS} on the
+server.
+
+To add this functionality, the \CI{sds} class could be extended. However, this
+would result in having to update all existing views that use the \CI{sds}
+class. Therefore, an extra class is added that contains the extra
+functionality. Programmers can choose to implement it for existing views in the
+future but are not obliged to. The publication function has the following
+signature:
+\begin{lstlisting}[caption={The \texttt{sdspub} class}]
+class sdspub v where
+ pub :: (v t Upd) -> v t Expr | type t
+\end{lstlisting}
+
+\glspl{SDS} in the \gls{mTask}-\gls{EDSL} are always attached to a \CI{Main}
+component. Thus, they are not usable in the \gls{Task} domain. To solve this,
+the \glspl{SDS} found in the \CI{Main} object are instantiated as real
+\gls{SDS} in the server. This poses a problem of naming because
+\glspl{SDS} in the \gls{mTask}-\gls{EDSL} are always anonymous at runtime. There
+is no way of labeling it since it is not a real entity, it is just a function.
+When \glspl{SDS} is instantiated and communicated with the device, they must be
+retrievable and identifiable. Internally this identification happens through
+numeric identifiers, but this is handy for programmers since.
+Therefore, an added class named \CI{namedsds} is added that provides the exact
+same functionality as the \gls{SDS} class but adds a \CI{String} parameter that
+can later be used to identify an \gls{SDS} in the bag of instantiated
+\glspl{SDS} that result from compilation. The types for this class are shown in
+Listing~\ref{lst:namedsds}. Again, an example is added for illustration.
+Retrieving the \gls{SDS} after compilation is shown in
+Section~\ref{sec:archexamples}.
+
+\begin{lstlisting}[label={lst:namedsds},%
+ caption={The \texttt{namedsds} class}]
+class namedsds v where
+ namedsds :: ((v t Upd) -> In (Named t String) (Main (v c s))) -> (Main (v c s)) | ...
+:: Named a b = Named infix 1 a b
+
+sdsExample :: Main (v Int Stmt)
+sdsExample = sds \x.0 Named "xvalue" In
+ {main= x =. x +. lit 42 }
+\end{lstlisting}
+++ /dev/null
-\Gls{mTask}-\glspl{SDS} on a client are available on the server as in the form
-of regular \gls{iTasks}-\glspl{SDS}. However, the same freedom that an
-\gls{SDS} has in the \gls{iTasks}-system is not given for \glspl{SDS} that
-reside on the client. Not all types are suitable to be located on a client,
-simply because it needs to be representable on clients. Also, not all \gls{SDS}
-types are possible to have on a device. Moreover, \glspl{SDS} behave a little
-different in an \gls{mTask} device compared to in the \gls{iTasks} system. In
-an \gls{iTasks} system, when the \gls{SDS} is updated, a broadcast to all
-watching \glspl{Task} in the system is made to notify them of the update.
-\glspl{SDS} can update often and the update might not be the final value it
-will get. Implementing the same functionality on the \gls{mTask} client would
-result in a lot of expensive unneeded bandwidth usage. Therefore a device must
-publish the \gls{SDS} explicitly to save bandwidth. Note that this means that
-the \gls{SDS} value on the device can be different compared to the value of the
-same \gls{SDS} on the server.
-
-To add this functionality, the \CI{sds} class could be extended. However, this
-would result in having to update all existing views that use the \CI{sds}
-class. Therefore, an extra class is added that contains the extra
-functionality. Programmers can choose to implement it for existing views in the
-future but are not obliged to. The publication function has the following
-signature:
-\begin{lstlisting}[caption={The \texttt{sdspub} class}]
-class sdspub v where
- pub :: (v t Upd) -> v t Expr | type t
-\end{lstlisting}
-
-Moreover, \glspl{SDS} in the \gls{mTask}-\gls{EDSL} are always anonymous. There
-is no way of labeling it since it is not a real entity, it is just a function.
-When an \gls{SDS} is sent to the device it must be retrievable and
-identifiable. It is not always clear which instantiated \gls{SDS} is which.
-Therefore, an added class named \CI{namedsds} is added that provides the exact
-same functionality as the \gls{SDS} class but adds a \CI{String} parameter that
-can later be used to identify an \gls{SDS}. The types for this class are as
-follows:
-
-\begin{lstlisting}[caption={The \texttt{namedsds} class}]
-class namedsds v where
- namedsds :: ((v t Upd)->In (Named t String) (Main (v c s))) -> (Main (v c s)) | type, mTaskType, toCode t
-:: Named a b = Named infix 1 a b
-\end{lstlisting}
\section{\gls{Task} Scheduling Strategy}
\input{mtaskext.taskstrat}
-\section{\gls{SDS} Strategy}
-\input{mtaskext.sdsstrat}
+\section{\gls{SDS} Properties}
+\input{mtaskext.sdsprop}
\section{Bytecode Compilation View}\label{sec:compiler}
\input{mtaskext.bytecode}
showtabs=false,
tabsize=4,
frame=L,
- language=Clean
}
% Increase the depth for the table of contenst
intro: Problem statement en introductie uitwijden
-emtsk: semantics, anders noemen en voorbeelden geven in strategies
-emtsk: Voorbeeldje voor namedsds
emtsk: examples, factorial vervangen
-devcs: iets met taken en argumenten zeggen
devcs: waarom kunnen taken geen andere taken starten
-devcs: duidelijker zijn dat je echt geen heap nodig hebt
iTaks: duidelijker maken wat "managing devices" betekend
-dvspc: Uitleggen hoe device spec gemaakt word
hbexm: Voorbeeld met de heartbeat sensor
hbexm: Instructies van de heartbeat sensor verkleinen
concl: Uitleggen hoe/of de probleemstelling opgelost is
repositories / msc-thesis1617.git / commitdiff