From: Mart Lubbers Date: Sat, 8 Jul 2017 12:21:09 +0000 (+0200) Subject: updates X-Git-Tag: final~19 X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=d73f951e0e2ece5174d6ce20b696cb6922897a0b;p=msc-thesis1617.git updates --- diff --git a/arch.communication.tex b/arch.communication.tex index d480797..0dcd83b 100644 --- a/arch.communication.tex +++ b/arch.communication.tex @@ -51,6 +51,52 @@ brevity. } \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 diff --git a/arch.devices.tex b/arch.devices.tex index c06d964..42f843c 100644 --- a/arch.devices.tex +++ b/arch.devices.tex @@ -31,9 +31,9 @@ only took about an hour. 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 @@ -95,7 +95,7 @@ support heaps nowadays, however, the functions for allocating and freeing 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. diff --git a/arch.tex b/arch.tex index 1fd4d4f..2f30b25 100644 --- a/arch.tex +++ b/arch.tex @@ -21,5 +21,5 @@ normal \gls{iTasks}-\glspl{Task}. \section{Communication}\label{sec:communication} \input{arch.communication} -\section{Example} +\section{Example}\label{sec:archexamples} \input{arch.example} diff --git a/mtaskext.sdsprop.tex b/mtaskext.sdsprop.tex new file mode 100644 index 0000000..029f9a0 --- /dev/null +++ b/mtaskext.sdsprop.tex @@ -0,0 +1,54 @@ +\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} diff --git a/mtaskext.sdsstrat.tex b/mtaskext.sdsstrat.tex deleted file mode 100644 index c4f2c2b..0000000 --- a/mtaskext.sdsstrat.tex +++ /dev/null @@ -1,41 +0,0 @@ -\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} diff --git a/mtaskext.tex b/mtaskext.tex index b89af96..e56d79c 100644 --- a/mtaskext.tex +++ b/mtaskext.tex @@ -10,8 +10,8 @@ interfering with the existing views. \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} diff --git a/thesis.pre b/thesis.pre index d36c6e5..e7fef0f 100644 --- a/thesis.pre +++ b/thesis.pre @@ -108,7 +108,6 @@ showtabs=false, tabsize=4, frame=L, - language=Clean } % Increase the depth for the table of contenst diff --git a/todo.txt b/todo.txt index 2a5889a..de9b7a4 100644 --- a/todo.txt +++ b/todo.txt @@ -1,12 +1,7 @@ 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