\end{chapterabstract}
There are at least 13.4 billion devices connected to the internet at the time of writing \citep{transforma_insights_current_2023}.
-Each of these sense, act, or otherwise, interacts with people, computers, and the environment.
-Despite their immense diversity in characteristics, they are all computers and they they all require software to operate.
+Each of these devices sense, act, or otherwise, interact with people, computers, and the environment.
+Despite their immense diversity, they are all computers and they they all require software to operate.
-An increasing number of these connected devices are so-called \emph{edge devices} that operate in the \gls{IOT}.
+An increasing number of these connected devices are so-called edge devices that operate in the \gls{IOT}.
Edge devices are the leaves of the \gls{IOT} systems.
-They perform the interaction with the physical world and are often physically embedded in the fabric itself, residing usually in hard-to-reach places such as light bulbs, clothing, smart electricity meters, buildings, or even farm animals.
-Typically, these edge devices are powered by microcontrollers.
+They perform the interaction with the physical world.
+It is not uncommon for edge devices to be physically embedded in the fabric itself.
+Typically they reside in hard-to-reach places such as light bulbs, clothing, smart electricity meters, buildings, or even farm animals.
+The majority of edge devices are powered by microcontrollers.
Microcontrollers are equipped with a lot of connectivity for integrating peripherals such as sensors and actuators.
The connectivity makes them very suitable to interact with their surroundings.
These miniature computers contain integrated circuits that accommodate a microprocessor designed for use in embedded applications.
The inflated hardware requirements are no problem for regular computers but impractical for the average edge device.
This is where \glspl{DSL} must be brought into play.
-\Glspl{DSL} are programming languages created with a specific domain in mind.
-Consequently, jargon does not have to be expressed in terms of the language itself, but they can be built-in features.
+\Glspl{DSL} are programming languages tailored to a specific domain.
+Consequently, jargon is not expressed in terms of the language itself, but are built-in language features.
Furthermore, the \gls{DSL} can eschew language or system features that are irrelevant for the domain.
Using \glspl{DSL}, hardware requirements can be drastically lowered, even while maintaining a high abstraction level for the specified domain.
\Cref{prt:top} is a monograph showing \gls{MTASK}, a \gls{TOP} \gls{DSL} for the \gls{IOT}.
Hence, the chapters in this episode are best read in order.
It introduces \gls{IOT} edge device programming, shows the complete \gls{MTASK} language, provides details on how \gls{MTASK} is integrated with \gls{ITASK}, shows how the byte code compiler is implemented, presents a guide for green computing with \gls{MTASK}, and ends with a conclusion and overview of future and related work.
-\Cref{prt:tvt} is a single chapter based on a journal article in which traditional tiered \gls{IOT} programming is qualitatively and quantitatively compared to tierless programming using a real-world application.
+\Cref{prt:tvt} consists of a single chapter that is based on a journal article.
+The chapter provides a qualitative and quantitative comparison of traditional tiered \gls{IOT} programming and tierless programming using a real-world application.
The chapter is readable independently.
The following sections in this prelude provide background material on the \gls{IOT}, \glspl{DSL}, and \gls{TOP} after which a detailed overview of the contributions is presented.
\section{Internet of things}%
\label{sec:back_iot}
The \gls{IOT} is growing rapidly, and it is changing the way people and machines interact with each other and the world.
-While the term \gls{IOT} briefly gained interest around 1999 to describe the communication of \gls{RFID} devices \citep{ashton_internet_1999,ashton_that_2009}, it probably already popped up halfway the eighties in a speech by \citet{lewis_speech_1985}:
+While the term \gls{IOT} briefly gained interest around 1999 to describe the communication of \gls{RFID} devices \citep{ashton_internet_1999,ashton_that_2009}, it probably already popped up halfway the eighties in a company speech by \citet{lewis_speech_1985}:
\begin{quote}
\emph{The \glsxtrlong{IOT}, or \glsxtrshort{IOT}, is the integration of people, processes and technology with connectable devices and sensors to enable remote monitoring, status, manipulation and evaluation of trends of such devices.}
\end{figure}
To explain the tiers, an example \gls{IOT} application---home automation---is dissected.
-Closest to the end-user is the presentation layer, it provides the interface between the user and the \gls{IOT} system.
+Closest to the end-user is the presentation layer.
+This layer provides the interface between the user and the \gls{IOT} system.
In home automation this may be a web interface, an app used on a phone, or wall-mounted tablet to interact with edge devices and view sensor data.
-The application layer provides the \glspl{API}, data interfaces, data storage processing, and data processing of \gls{IOT} systems.
+The application layer is the core of the system.
+It provides the \glspl{API}, data interfaces, data storage processing, and data processing of \gls{IOT} systems.
A cloud server or local server provides this layer in a typical home automation application.
The perception layer---also called edge layer---collects the data and interacts with the environment.
Furthermore, \gls{IOT} edge devices are in general not powerful enough to run or interpret \gls{CLEAN}\slash\gls{ABC} code, they just lack the processor speed and memory.
To bridge this gap, \gls{MTASK} is developed, a domain-specific \gls{TOP} system for \gls{IOT} edge devices that is integrated in \gls{ITASK} \citep{koopman_task-based_2018}.
The \gls{ITASK} language abstracts away from details such as user interfaces, data storage, client-side platforms, and persistent workflows.
-On the other hand, \gls{MTASK} offers abstractions for edge layer-specific details such as the heterogeneity of architectures, platforms, and frameworks; peripheral access; (multi) task scheduling; and lowering energy consumption.
+On the other hand, \gls{MTASK} offers abstractions for edge layer-specific details such as the heterogeneity of architectures, platforms, and frameworks; peripheral access; task scheduling; and lowering energy consumption.
The \gls{MTASK} system is seamlessly integrated with \gls{ITASK}.
Tasks in \gls{MTASK} are integrated in such a way that they function as regular \gls{ITASK} tasks.
Once connected, the \cleaninline{intBlink} task is sent to the device (\cref{lst:intro_liftmtask}) and, in parallel, a web editor is shown that updates the value of the interval \gls{SDS} (\cref{lst:intro_editor,fig:intro_blink_int}).
To allow terminating of the task, the \gls{ITASK} task ends with a sequential operation that returns a constant value when the button is pressed, making the task stable.
-\cleaninputlisting[firstline=10,lastline=18,numbers=left,caption={The \gls{ITASK} code for the interactive blinking application.},label={lst:intro_blink}]{lst/blink.icl}
+\cleaninputlisting[float={!ht},firstline=10,lastline=18,numbers=left,caption={The \gls{ITASK} code for the interactive blinking application.},label={lst:intro_blink}]{lst/blink.icl}
\begin{figure}
\centering
The main expression of the program calls the \cleaninline{blink} function with an initial state.
This function on \crefrange{lst:intro:blink_fro}{lst:intro:blink_to} first reads the interval \gls{SDS}, waits the specified delay, writes the state to the \gls{GPIO} pin, and calls itself recursively using the inverse of the state in order to run continuously.
-\begin{lstClean}[numbers=left,belowskip=0pt]
-intBlink :: (Shared sds Int) -> Main (MTask v Int) | mtask v & ...\end{lstClean}
-\cleaninputlisting[aboveskip=0pt,firstnumber=4,firstline=23,numbers=left,caption={The \gls{MTASK} code for the interactive blinking application.},label={lst:intro_blink_mtask}]{lst/blink.icl}
+\cleaninputlisting[float={!ht},linerange={23-,25-33},numbers=left,caption={The \gls{MTASK} code for the interactive blinking application.},label={lst:intro_blink_mtask}]{lst/blink.icl} %chktex 8
\subsection{Other TOP languages}
While \gls{ITASK} conceived \gls{TOP}, it is no longer the only \gls{TOP} system.
The paper also serves as a gentle introduction to, and contains a thorough literature study on \glsxtrlong{TH}.
\end{enumerate}
-\todo[inline]{add stack paper?}
-%\paragraph{Other publications on eDSLs:}
-%Furthermore, I co-authored a paper that is not part of the \gls{MTASK} system yet and hence not part of the dissertation.
+%\paragraph{In preparation}
+%Furthermore, there are some papers either in preparation or under review describing methods for creating \glspl{DSL}.
+%They describe techniques found while developing the \gls{MTASK} \gls{DSL} that have not made it (yet) into the system.
+%Hence, they are not part of the dissertation.
%
-%\begin{enumerate}[resume]
-% \item \emph{Strongly-Typed Multi-\kern-2.5ptView Stack-\kern-1.25ptBased Computations} \citep{koopman_strongly-typed_2022}\label{enum:stack-based} shows how to create type-safe \glspl{EDSL} representing stack-based computations.
+%\begin{itemize}
+% \item \emph{Strongly-Typed Multi-\kern-2ptView Stack-\kern-1.25ptBased Computations} shows how to create type-safe \glspl{EDSL} representing stack-based computations.
% Instead of encoding the arguments to a function as arguments in the host language, stack-based approaches use a run time stack that contains the arguments.
% By encoding the required contents of the stack in the types, such systems can be made type safe.
-%\end{enumerate}
+%
+% \item \emph{Template Metaprogramming using Two-Stage Generic Functions} shows how a sufficiently rich generic programming system can achieve much of the same functionality as template metaprogramming.
+% The generic programming functionality of \gls{Clean} is built into the compiler.
+% As a result, metadata of the generic types is added to the generic structure.
+% From this metadata, we can destill not only type and constructor names but also arities, fixity, kinds, types, \etc{}.
+% This allows us, by
+%\end{itemize}
\paragraph{Contribution:}
The papers of which I am first author are solely written by me, there were weekly meetings with co-authors in which we discussed and refined the ideas.
intBlink :: (Shared sds Int) -> Main (MTask v Int)
| mtask, lowerSds v & RWShared sds & TC sds () Int Int
+/*
+intBlink :: (Shared sds Int) -> Main (MTask v Int) | mtask v & ...
+*/
intBlink iInterval =
declarePin D2 PMOutput \ledPin-> /*\label{lst:intro:declarePin}*/
lowerSds \mInterval=iInterval/*\label{lst:intro:liftsds}*/
\newabbreviation{DHT}{DHT}{digital humidity and temperature}
\newabbreviation{DSL}{DSL}{domain-specific language}
\newabbreviation{DVFS}{DVFS}{dynamic voltage and frequency scaling}
-\newabbreviation{EDSL}{EDSL}{embedded \glsxtrlong{DSL}}
+\newabbreviation{EDSL}{eDSL}{embedded \glsxtrlong{DSL}}
\newabbreviation[prefixfirst={a\ },prefix={an\ }]{FP}{FP}{functional programming}
\newabbreviation[prefixfirst={a\ },prefix={an\ }]{FRP}{FRP}{functional reactive programming}
\newabbreviation[prefixfirst={a\ },prefix={an\ }]{FPGA}{FPGA}{field-programmable gate array}
\newabbreviation{TTH}{TTH}{typed \glsxtrlong{TH}}
\newabbreviation{TVOC}{TVOC}{total volatile organic compounds}
\newabbreviation{UI}{UI}{user interface}
-\newabbreviation{UOD}{UOD}{universe of discourse}
-\newabbreviation{UOG}{UOG}{University of Glasgow}
+\newabbreviation{UOD}{UoD}{universe of discourse}
+\newabbreviation{UOG}{UoG}{University of Glasgow}
\newabbreviation{VM}{VM}{virtual machine}
% Glossaries
\begingroup%
\let\cleardoublepage\clearpage
\printglossary[style=mcolindex]%
- \printglossary[type=\acronymtype,style=mcolindex]%
\endgroup
}{%
}
\bookmark[level=section,dest=dedication]{Dedication}
\subfile{front/dedication}
-% Reset glossary and thus the acronyms
-\glsresetall{}
-
% The actual document
\mainmatter%
\mainmatterfancy%
\setcounter{chapter}{-1}
+\glsresetall{} % Reset glossary and thus the acronyms
% Introduction
\subfile{intro/intro}
Edge devices in \gls{IOT} systems are typically slow but energy efficient and do not have the memory to run the naturally heap-heavy feature-packed functional programs that \gls{ITASK} programs are.
The \gls{MTASK} system bridges this gap by providing a domain-specific \gls{TOP} language for \gls{IOT} edge devices.
Domain-specific knowledge is embedded in the language and execution platform; and unnecessary features for edge devices are removed to drastically lowere the hardware requirements.
+Programs in \gls{MTASK} are written in the same abstraction level as \gls{ITASK} in the \gls{MTASK} \gls{DSL}.
+When executed, they are fully integrated in the \gls{ITASK} host, allowing for programming entire \gls{IOT} systems from a single abstraction level, source code, and programming paradigm.
\section{Hello world!}
Traditionally, the first program that one writes when trying a new language is the so-called \emph{Hello World!} program.
Due to the lack of an \gls{OS}, writing applications that perform multiple tasks at the same time is error prone, becomes complex, requires a lot of boilerplate, and needs manual scheduling code.
With the \gls{MTASK} system, a \gls{TOP} programming language for \gls{IOT} edge devices, this limitation can be overcome.
Since much domain-specific knowledge is built into the language and \gls{RTS}, the hardware requirements can be kept relatively low while maintaining a high abstraction level.
-Furthermore, the programs are automatically integrated with \gls{ITASK}, allowing for data sharing, task coordination, and dynamic construction of tasks.
+Furthermore, the programs are automatically integrated with \gls{ITASK}, a \gls{TOP} system for creating interactive distributed web applications, allowing for data sharing, task coordination, and dynamic construction of tasks.
The following chapters thoroughly introduce all aspects of the \gls{MTASK} system.
First the language setup and interface is shown in \cref{chp:mtask_dsl}.
\begin{tabular}{ccccccccc}
\toprule
& \multicolumn{4}{c}{\Gls{WEMOS} D1 mini}
- & \multicolumn{4}{c}{Adafruit Feather M0 Wifi} \\
+ & \multicolumn{4}{c}{Adafruit Feather M0 \gls{WIFI}} \\
\midrule
& active & modem & light & deep & active & modem & light & deep\\
& & sleep & sleep & sleep & & sleep & sleep & sleep\\
Otherwise, no value is emitted.
\section{Conclusion}
-\todo[inline]{Conclusion}
+This chapter show how we can automatically associate execution intervals to tasks.
+Based on these intervals, we can delay the executions of those tasks.
+When all task executions can be delayed, the microprocessor executing those tasks can go to sleep mode to reduce its energy consumption.
+This is a rather difficult problem that must be solved dynamically, since we make no assumptions on the number and nature of the tasks that will be allocated to an IoT node.
+Furthermore, the execution intervals offer an elegant and efficient way to add interrupts to the language.
+Those interrupts offer a more elegant and energy efficient implementation of watching an input than polling this input.
+
+The actual reduction of the energy is of course highly dependent on the number and nature of the task shipped to the edge device.
+Our examples show a reduction in energy consumption of two orders of magnitude.
+Those reductions are a necessity for edge devices running of battery power.
+Given the exploding number of \gls{IOT} edge devices, such savings are also mandatory for other nodes to limit the total power consumption of the \gls{IOT}.
\input{subfilepostamble}
\end{document}
This chapter shows the implementation of the \gls{MTASK} system by:
\begin{itemize}
\item showing the compilation and execution toolchain;
- \item elaborating on the implementation and architecture of the \gls{RTS} of \gls{MTASK};
\item showing the implementation of the byte code compiler for the \gls{MTASK} language;
+ \item elaborating on the implementation and architecture of the \gls{RTS} of \gls{MTASK};
\item and explaining the machinery used to automatically serialise and deserialise data to-and-fro the device.
\end{itemize}
\end{chapterabstract}
The microcontrollers usually have flash-based program memory which wears out fairly quickly.
For example, the flash memory of the popular atmega328p powering the \gls{ARDUINO} UNO is rated for \num{10000} write cycles.
While this sounds like a lot, if new tasks are sent to the device every minute or so, a lifetime of only seven days is guaranteed.
-Hence, for dynamic applications, storing the program in the \gls{RAM} of the device and interpreting this code is necessary in order to save precious write cycles of the program memory.
+Hence, for dynamic applications, storing the program in the \gls{RAM} of the device and thus interpreting this code is necessary in order to save precious write cycles of the program memory.
In the \gls{MTASK} system, the \gls{MTASK} \gls{RTS}, a domain-specific \gls{OS}, is responsible for interpreting the programs.
Programs in \gls{MTASK} are \gls{DSL} terms constructed at run time in an \gls{ITASK} system.
\Cref{fig:toolchain} shows the compilation and execution toolchain of such programs.
First, the source code is compiled to a byte code specification, this specification contains the compiled main expression, the functions, and the \gls{SDS} and peripheral configuration.
How an \gls{MTASK} task is compiled to this specification is shown in \cref{sec:compiler_imp}.
-This package is then sent to the \gls{RTS} of the device for execution, shown in \cref{sec:compiler_rts}.
+This package is then sent to the \gls{RTS} of the device for execution.
+In order to execute a task, first the main expression is evaluated in the interpreter, resulting in a task tree.
+Using small-step reduction, this task tree is continuously rewritten by the rewrite engine of the \gls{RTS}.
+At times, the reduction requires the evaluation of expressions, using the interpreter.
+During every rewrite step, a task value is produced.
On the device, the \gls{RTS} may have multiple tasks at the same time active.
+By interleavig the rewrite steps, parallel operation is achieved.
+The design, architecture and implementation of the \gls{RTS} is shown in \cref{sec:compiler_rts}.
\begin{figure}
\centering
\label{fig:toolchain}
\end{figure}
-\section{Run-time system}\label{sec:compiler_rts}
-The \gls{RTS} is a customisable domain-specific \gls{OS} that takes care of the execution of tasks.
-Furthermore, it also takes care of low-level mechanisms such as the communication, multitasking, and memory management.
-Once a device is programmed with the \gls{MTASK} \gls{RTS}, it can continuously receive new tasks without the need for reprogramming.
-The \gls{OS} is written in portable \ccpp{} and only contains a small device-specific portion.
-In order to keep the abstraction level high and the hardware requirements low, much of the high-level functionality of the \gls{MTASK} language is implemented not in terms of lower-level constructs from \gls{MTASK} language but in terms of \ccpp{} code.
-
-Most microcontrollers software consists of a cyclic executive instead of an \gls{OS}, this one loop function is continuously executed and all work is performed there.
-In the \gls{RTS} of the \gls{MTASK} system, there is also such an event loop function.
-It is a function with a relatively short execution time that gets called repeatedly.
-The event loop consists of three distinct phases.
-After doing the three phases, the devices goes to sleep for as long as possible (see \cref{chp:green_computing_mtask} for more details on task scheduling).
-
-\subsection{Communication phase}
-In the first phase, the communication channels are processed.
-The exact communication method is a customisable device-specific option baked into the \gls{RTS}.
-The interface is kept deliberately simple and consists of two layers: a link interface and a communication interface.
-Besides opening, closing and cleaning up, the link interface has three functions that are shown in \cref{lst:link_interface}.
-Consequently, implementing this link interface is very simple but it is still possible to implement more advanced link features such as buffering.
-There are implementations for this interface for serial or \gls{WIFI} connections using \gls{ARDUINO}, and \gls{TCP} connections for Linux.
-
-\begin{lstArduino}[caption={Link interface of the \gls{MTASK} \gls{RTS}.},label={lst:link_interface}]
-bool link_input_available(void);
-uint8_t link_read_byte(void);
-void link_write_byte(uint8_t b);
-\end{lstArduino}
-
-The communication interface abstracts away from this link interface and is typed instead.
-It contains only two functions as seen in \cref{lst:comm_interface}.
-There are implementations for direct communication, or communication using an \gls{MQTT} broker.
-Both use the automatic serialisation and deserialisation shown in \cref{sec:ccodegen}.
-
-\begin{lstArduino}[caption={Communication interface of the \gls{MTASK} \gls{RTS}.},label={lst:comm_interface}]
-struct MTMessageTo receive_message(void);
-void send_message(struct MTMessageFro msg);
-\end{lstArduino}
-
-Processing the received messages from the communication channels happens synchronously and the channels are exhausted completely before moving on to the next phase.
-There are several possible messages that can be received from the server:
-
-\begin{description}
- \item[SpecRequest]
- is a message instructing the device to send its specification and it is received immediately after connecting.
- The \gls{RTS} responds with a \texttt{Spec} answer containing the specification.
- \item[TaskPrep]
- tells the device a task is on its way.
- Especially on faster connections, it may be the case that the communication buffers overflow because a big message is sent while the \gls{RTS} is busy executing tasks.
- This message allows the \gls{RTS} to postpone execution for a while, until the larger task has been received.
- The server sends the task only after the device acknowledged the preparation by by sending a \texttt{TaskPrepAck} message.
- \item[Task]
- contains a new task, its peripheral configuration, the \glspl{SDS}, and the byte code.
- The new task is immediately copied to the task storage but is only initialised during the next phase.
- The device acknowledges the task by sending a \texttt{TaskAck} message.
- \item[SdsUpdate]
- notifies the device of the new value for a lowered \gls{SDS}.
- The old value of the lowered \gls{SDS} is immediately replaced with the new one.
- There is no acknowledgement required.
- \item[TaskDel]
- instructs the device to delete a running task.
- Tasks are automatically deleted when they become stable.
- However, a task may also be deleted when the surrounding task on the server is deleted, for example when the task is on the left-hand side of a step combinator and the condition to step holds.
- The device acknowledges the deletion by sending a \texttt{TaskDelAck}.
- \item[Shutdown]
- tells the device to reset.
-\end{description}
-
-\subsection{Execution phase}
-The second phase performs one execution step for all tasks that wish for it.
-Tasks are ordered in a priority queue ordered by the time a task needs to execute, the \gls{RTS} selects all tasks that can be scheduled, see \cref{sec:scheduling} for more details.
-Execution of a task is always an interplay between the interpreter and the rewriter.
-
-When a new task is received, the main expression is evaluated to produce a task tree.
-A task tree is a tree structure in which each node represents a task combinator and the leaves are basic tasks.
-If a task is not initialized yet, i.e.\ the pointer to the current task tree is still null, the byte code of the main function is interpreted.
-The main expression always produces a task tree.
-Execution of a task consists of continuously rewriting the task until its value is stable.
-
-Rewriting is a destructive process, i.e.\ the rewriting is done in place.
-The rewriting engine uses the interpreter when needed, e.g.\ to calculate the step continuations.
-The rewriter and the interpreter use the same stack to store intermediate values.
-Rewriting steps are small so that interleaving results in seemingly parallel execution.
-In this phase new task tree nodes may be allocated.
-Both rewriting and initialization are atomic operations in the sense that no processing on \glspl{SDS} is done other than \gls{SDS} operations from the task itself.
-The host is notified if a task value is changed after a rewrite step by sending a \texttt{TaskReturn} message.
-
-Take for example a blink task for which the code is shown in \cref{lst:blink_code}.
-
-\begin{lstClean}[caption={Code for a blink program.},label={lst:blink_code}]
-fun \blink=(\st->delay (lit 500) >>|. writeD d3 st >>=. blink o Not)
-In {main = blink true}
-\end{lstClean}
-
-On receiving this task, the task tree is still null and the initial expression \cleaninline{blink true} is evaluated by the interpreter.
-This results in the task tree shown in \cref{fig:blink_tree}.
-Rewriting always starts at the top of the tree and traverses to the leaves, the basic tasks that do the actual work.
-The first basic task encountered is the \cleaninline{delay} task, that yields no value until the time, \qty{500}{\ms} in this case, has passed.
-When the \cleaninline{delay} task yielded a stable value after a number of rewrites, the task continues with the right-hand side of the \cleaninline{>>\|.} combinator.
-This combinator has a \cleaninline{writeD} task at the left-hand side that becomes stable after one rewrite step in which it writes the value to the given pin.
-When \cleaninline{writeD} becomes stable, the written value is the task value that is observed by the right-hand side of the \cleaninline{>>=.} combinator.
-This will call the interpreter to evaluate the expression, now that the argument of the function is known.
-The result of the function is again a task tree, but now with different arguments to the tasks, e.g.\ the state in \cleaninline{writeD} is inversed.
-
-\begin{figure}
- \centering
- \includestandalone{blinktree}
- \caption{The task tree for a blink task in \cref{lst:blink_code} in \gls{MTASK}.}%
- \label{fig:blink_tree}
-\end{figure}
-
-\subsection{Memory management}
-The third and final phase is memory management.
-The \gls{MTASK} \gls{RTS} is designed to run on systems with as little as \qty{2}{\kibi\byte} of \gls{RAM}.
-Aggressive memory management is therefore vital.
-Not all firmwares for microprocessors support heaps and---when they do---allocation often leaves holes when not used in a \emph{last in first out} strategy.
-The \gls{RTS} uses a chunk of memory in the global data segment with its own memory manager tailored to the needs of \gls{MTASK}.
-The size of this block can be changed in the configuration of the \gls{RTS} if necessary.
-On an \gls{ARDUINO} UNO---equipped with \qty{2}{\kibi\byte} of \gls{RAM}---the maximum viable size is about \qty{1500}{\byte}.
-The self-managed memory uses a similar layout as the memory layout for \gls{C} programs only the heap and the stack are switched (see \cref{fig:memory_layout}).
-
-\begin{figure}
- \centering
- \includestandalone{memorylayout}
- \caption{Memory layout in the \gls{MTASK} \gls{RTS}.}\label{fig:memory_layout}
-\end{figure}
-
-A task is stored below the stack and its complete state is a \gls{CLEAN} record contain most importantly the task id, a pointer to the task tree in the heap (null if not initialised yet), the current task value, the configuration of \glspl{SDS}, the configuration of peripherals, the byte code and some scheduling information.
-
-In memory, task data grows from the bottom up and the interpreter stack is located directly on top of it growing in the same direction.
-As a consequence, the stack moves when a new task is received.
-This never happens within execution because communication is always processed before execution.
-Values in the interpreter are always stored on the stack.
-Compound data types are stored unboxed and flattened.
-Task trees grow from the top down as in a heap.
-This approach allows for flexible ratios, i.e.\ many tasks and small trees or few tasks and big trees.
-
-Stable tasks, and unreachable task tree nodes are removed.
-If a task is to be removed, tasks with higher memory addresses are moved down.
-For task trees---stored in the heap---the \gls{RTS} already marks tasks and task trees as trash during rewriting so the heap can be compacted in a single pass.
-This is possible because there is no sharing or cycles in task trees and nodes contain pointers pointers to their parent.
-
\section{Compiler}\label{sec:compiler_imp}
\subsection{Compiler infrastructure}
-The bytecode compiler interpretation for the \gls{MTASK} language is implemented as a monad stack containing a writer monad and a state monad.
+The byte code compiler interpretation for the \gls{MTASK} language is implemented as a monad stack containing a writer monad and a state monad.
The writer monad is used to generate code snippets locally without having to store them in the monadic values.
The state monad accumulates the code, and stores the state the compiler requires.
\Cref{lst:compiler_state} shows the data type for the state, storing:
}\end{lstClean}
% VimTeX: SynIgnore off
+\section{Run-time system}\label{sec:compiler_rts}
+The \gls{RTS} is a customisable domain-specific \gls{OS} that takes care of the execution of tasks.
+Furthermore, it also takes care of low-level mechanisms such as the communication, multitasking, and memory management.
+Once a device is programmed with the \gls{MTASK} \gls{RTS}, it can continuously receive new tasks without the need for reprogramming.
+The \gls{OS} is written in portable \ccpp{} and only contains a small device-specific portion.
+In order to keep the abstraction level high and the hardware requirements low, much of the high-level functionality of the \gls{MTASK} language is implemented not in terms of lower-level constructs from \gls{MTASK} language but in terms of \ccpp{} code.
+
+Most microcontrollers software consists of a cyclic executive instead of an \gls{OS}, this one loop function is continuously executed and all work is performed there.
+In the \gls{RTS} of the \gls{MTASK} system, there is also such an event loop function.
+It is a function with a relatively short execution time that gets called repeatedly.
+The event loop consists of three distinct phases.
+After doing the three phases, the devices goes to sleep for as long as possible (see \cref{chp:green_computing_mtask} for more details on task scheduling).
+
+\subsection{Communication phase}
+In the first phase, the communication channels are processed.
+The exact communication method is a customisable device-specific option baked into the \gls{RTS}.
+The interface is kept deliberately simple and consists of two layers: a link interface and a communication interface.
+Besides opening, closing and cleaning up, the link interface has three functions that are shown in \cref{lst:link_interface}.
+Consequently, implementing this link interface is very simple but it is still possible to implement more advanced link features such as buffering.
+There are implementations for this interface for serial or \gls{WIFI} connections using \gls{ARDUINO}, and \gls{TCP} connections for Linux.
+
+\begin{lstArduino}[caption={Link interface of the \gls{MTASK} \gls{RTS}.},label={lst:link_interface}]
+bool link_input_available(void);
+uint8_t link_read_byte(void);
+void link_write_byte(uint8_t b);
+\end{lstArduino}
+
+The communication interface abstracts away from this link interface and is typed instead.
+It contains only two functions as seen in \cref{lst:comm_interface}.
+There are implementations for direct communication, or communication using an \gls{MQTT} broker.
+Both use the automatic serialisation and deserialisation shown in \cref{sec:ccodegen}.
+
+\begin{lstArduino}[caption={Communication interface of the \gls{MTASK} \gls{RTS}.},label={lst:comm_interface}]
+struct MTMessageTo receive_message(void);
+void send_message(struct MTMessageFro msg);
+\end{lstArduino}
+
+Processing the received messages from the communication channels happens synchronously and the channels are exhausted completely before moving on to the next phase.
+There are several possible messages that can be received from the server:
+
+\begin{description}
+ \item[SpecRequest]
+ is a message instructing the device to send its specification and it is received immediately after connecting.
+ The \gls{RTS} responds with a \texttt{Spec} answer containing the specification.
+ \item[TaskPrep]
+ tells the device a task is on its way.
+ Especially on faster connections, it may be the case that the communication buffers overflow because a big message is sent while the \gls{RTS} is busy executing tasks.
+ This message allows the \gls{RTS} to postpone execution for a while, until the larger task has been received.
+ The server sends the task only after the device acknowledged the preparation by by sending a \texttt{TaskPrepAck} message.
+ \item[Task]
+ contains a new task, its peripheral configuration, the \glspl{SDS}, and the byte code.
+ The new task is immediately copied to the task storage but is only initialised during the next phase.
+ The device acknowledges the task by sending a \texttt{TaskAck} message.
+ \item[SdsUpdate]
+ notifies the device of the new value for a lowered \gls{SDS}.
+ The old value of the lowered \gls{SDS} is immediately replaced with the new one.
+ There is no acknowledgement required.
+ \item[TaskDel]
+ instructs the device to delete a running task.
+ Tasks are automatically deleted when they become stable.
+ However, a task may also be deleted when the surrounding task on the server is deleted, for example when the task is on the left-hand side of a step combinator and the condition to step holds.
+ The device acknowledges the deletion by sending a \texttt{TaskDelAck}.
+ \item[Shutdown]
+ tells the device to reset.
+\end{description}
+
+\subsection{Execution phase}
+The second phase performs one execution step for all tasks that wish for it.
+Tasks are ordered in a priority queue ordered by the time a task needs to execute, the \gls{RTS} selects all tasks that can be scheduled, see \cref{sec:scheduling} for more details.
+Execution of a task is always an interplay between the interpreter and the rewriter.
+
+When a new task is received, the main expression is evaluated to produce a task tree.
+A task tree is a tree structure in which each node represents a task combinator and the leaves are basic tasks.
+If a task is not initialized yet, i.e.\ the pointer to the current task tree is still null, the byte code of the main function is interpreted.
+The main expression always produces a task tree.
+Execution of a task consists of continuously rewriting the task until its value is stable.
+
+Rewriting is a destructive process, i.e.\ the rewriting is done in place.
+The rewriting engine uses the interpreter when needed, e.g.\ to calculate the step continuations.
+The rewriter and the interpreter use the same stack to store intermediate values.
+Rewriting steps are small so that interleaving results in seemingly parallel execution.
+In this phase new task tree nodes may be allocated.
+Both rewriting and initialization are atomic operations in the sense that no processing on \glspl{SDS} is done other than \gls{SDS} operations from the task itself.
+The host is notified if a task value is changed after a rewrite step by sending a \texttt{TaskReturn} message.
+
+Take for example a blink task for which the code is shown in \cref{lst:blink_code}.
+
+\begin{lstClean}[caption={Code for a blink program.},label={lst:blink_code}]
+fun \blink=(\st->delay (lit 500) >>|. writeD d3 st >>=. blink o Not)
+In {main = blink true}
+\end{lstClean}
+
+On receiving this task, the task tree is still null and the initial expression \cleaninline{blink true} is evaluated by the interpreter.
+This results in the task tree shown in \cref{fig:blink_tree}.
+Rewriting always starts at the top of the tree and traverses to the leaves, the basic tasks that do the actual work.
+The first basic task encountered is the \cleaninline{delay} task, that yields no value until the time, \qty{500}{\ms} in this case, has passed.
+When the \cleaninline{delay} task yielded a stable value after a number of rewrites, the task continues with the right-hand side of the \cleaninline{>>\|.} combinator.
+This combinator has a \cleaninline{writeD} task at the left-hand side that becomes stable after one rewrite step in which it writes the value to the given pin.
+When \cleaninline{writeD} becomes stable, the written value is the task value that is observed by the right-hand side of the \cleaninline{>>=.} combinator.
+This will call the interpreter to evaluate the expression, now that the argument of the function is known.
+The result of the function is again a task tree, but now with different arguments to the tasks, e.g.\ the state in \cleaninline{writeD} is inversed.
+
+\begin{figure}
+ \centering
+ \includestandalone{blinktree}
+ \caption{The task tree for a blink task in \cref{lst:blink_code} in \gls{MTASK}.}%
+ \label{fig:blink_tree}
+\end{figure}
+
+\subsection{Memory management}
+The third and final phase is memory management.
+The \gls{MTASK} \gls{RTS} is designed to run on systems with as little as \qty{2}{\kibi\byte} of \gls{RAM}.
+Aggressive memory management is therefore vital.
+Not all firmwares for microprocessors support heaps and---when they do---allocation often leaves holes when not used in a \emph{last in first out} strategy.
+The \gls{RTS} uses a chunk of memory in the global data segment with its own memory manager tailored to the needs of \gls{MTASK}.
+The size of this block can be changed in the configuration of the \gls{RTS} if necessary.
+On an \gls{ARDUINO} UNO---equipped with \qty{2}{\kibi\byte} of \gls{RAM}---the maximum viable size is about \qty{1500}{\byte}.
+The self-managed memory uses a similar layout as the memory layout for \gls{C} programs only the heap and the stack are switched (see \cref{fig:memory_layout}).
+
+\begin{figure}
+ \centering
+ \includestandalone{memorylayout}
+ \caption{Memory layout in the \gls{MTASK} \gls{RTS}.}\label{fig:memory_layout}
+\end{figure}
+
+A task is stored below the stack and its complete state is a \gls{CLEAN} record contain most importantly the task id, a pointer to the task tree in the heap (null if not initialised yet), the current task value, the configuration of \glspl{SDS}, the configuration of peripherals, the byte code and some scheduling information.
+
+In memory, task data grows from the bottom up and the interpreter stack is located directly on top of it growing in the same direction.
+As a consequence, the stack moves when a new task is received.
+This never happens within execution because communication is always processed before execution.
+Values in the interpreter are always stored on the stack.
+Compound data types are stored unboxed and flattened.
+Task trees grow from the top down as in a heap.
+This approach allows for flexible ratios, i.e.\ many tasks and small trees or few tasks and big trees.
+
+Stable tasks, and unreachable task tree nodes are removed.
+If a task is to be removed, tasks with higher memory addresses are moved down.
+For task trees---stored in the heap---the \gls{RTS} already marks tasks and task trees as trash during rewriting so the heap can be compacted in a single pass.
+This is possible because there is no sharing or cycles in task trees and nodes contain pointers pointers to their parent.
+
+
\section{C code generation}\label{sec:ccodegen}
All communication between the \gls{ITASK} server and the \gls{MTASK} server is type parametrised.
From the structural representation of the type, a \gls{CLEAN} parser and printer is constructed using generic programming.
\section{Conclusion}
It is not straightforward to execute \gls{MTASK} tasks on resources-constrained \gls{IOT} edge devices.
-To achieve this, the terms in the \gls{DSL} are compiled to domain-specific byte code.
+To achieve this, the terms in the \gls{DSL} are compiled to compact domain-specific byte code.
This byte code is sent for interpretation to the light-weight \gls{RTS} of the edge device.
-The \gls{RTS} first evaluates the main expression.
+The \gls{RTS} first evaluates the main expression in the interpreter.
The result of this evaluation, a run time representation of the task, is a task tree.
-This task tree is rewritten according to rewrite rules until a stable value is observed.
+This task tree is rewritten according to small-step reduction rules until a stable value is observed.
Rewriting multiple tasks at the same time is achieved by interleaving the rewrite steps, resulting in seamingly parallel execution of the tasks.
-Furthermore, the \gls{RTS} automates communication and coordinates multi tasking.
+All communication, including the serialisation and deserialisation, between the server and the \gls{RTS} is automated.
+From the structural representation of the types, printers and parsers are generated for the server and the client.
\input{subfilepostamble}
\end{document}
\end{itemize}
\end{chapterabstract}
-The \gls{MTASK} language is a multi-view \gls{DSL}, there are multiple interpretations possible for a single \gls{MTASK} term.
-When using the byte code compiler (\cleaninline{:: BCInterpret a}) \gls{DSL} interpretation, \gls{MTASK} tasks are fully integrated in \gls{ITASK}.
+The \gls{MTASK} system is a \gls{TOP} \gls{DSL} for edge devices.
+It is a multi-view \gls{DSL}, there are multiple interpretations possible for a single \gls{MTASK} term.
+The main interpretation of \gls{MTASK} terms is the byte code compiler, \cleaninline{:: BCInterpret a}.
+When using this interpretation and a few integration functions, \gls{MTASK} tasks are fully integrated in \gls{ITASK}.
They execute as regular \gls{ITASK} tasks and they can access \glspl{SDS} from \gls{ITASK}.
Devices in the \gls{MTASK} system are set up with a domain-specific \gls{OS} and become little \gls{TOP} engines in their own respect, being able to execute tasks.
All details regarding interoperation are automatically taken care of.
The following section contains an elaborate example using all integration functions that has deliberately been placed after the conclusion so that the code listing and description are on facing pages.
-%\begin{figure}[p]
+\begin{figure}[p]
+ \begin{fullpage}
% \begin{leftfullpage}
-% \vspace{\headsep}
-%\section{Home automation}
-%This section presents an interactive home automation program (\cref{lst:example_home_automation}) to illustrate the integration of the \gls{MTASK} language and the \gls{ITASK} system.
-%It consists of a web interface for the user to control which tasks are executed on either one of two connected devices: an \gls{ARDUINO} UNO, connected via a serial port; and an ESP8266 based prototyping board called NodeMCU, connected via \gls{TCP} over \gls{WIFI}.
-%
-%\Crefrange{lst:example:spec1}{lst:example:spec2} show the specification for the devices.
-%The UNO is connected via serial using the unix filepath \path{/dev/ttyACM0} and the default serial port settings.
-%The NodeMCU is connected via \gls{WIFI} and hence the \cleaninline{TCPSettings} record is used.
-%Both types have \cleaninline{channelSync} instances.
-%
-%The code consists of an \gls{ITASK} part and several \gls{MTASK} parts.
-%\Crefrange{lst:example:task1}{lst:example:task2} contains the \gls{ITASK} task that coordinates the \gls{IOT} application.
-%First the devices are connected (\crefrange{lst:example:conn1}{lst:example:conn2}) followed by launching a \cleaninline{parallel} task, visualized as a tabbed window, and a shutdown button to terminate the program (\crefrange{lst:example:par1}{lst:example:par2}).
-%This parallel task is the controller of the tasks that run on the edge devices.
-%It contains one task that allows adding new tasks (using \cleaninline{appendTask}) and all other tasks in the process list will be \gls{MTASK} tasks once they are added by the user.
-%The controller task, \cleaninline{chooseTask} as shown in \crefrange{lst:example:ct1}{lst:example:ct2}, allows the user to pick a task, and sending it to the specified device.
-%Tasks are picked by index from the \cleaninline{tasks} list (\crefrange{lst:example:tasks1}{lst:example:tasks2}) using \cleaninline{enterChoice}.
-%The interface that is generated for this is seen in \cref{fig:example_screenshots1}.
-%After selecting the task, a device is selected (see \cref{fig:example_screenshots2,lst:example:selectdev}).
-%When both a task and a device are selected, an \gls{ITASK} task is added to the process list using \cleaninline{appendTask}.
-%Using the helper function \cleaninline{mkTask}, the actual task is selected from the \cleaninline{tasks} list and executed by providing it the device argument.
-%For example, when selecting the \cleaninline{temperature} task, the current temperature is shown to the user (\cref{fig:example_screenshots3}).
-%This task just sends a simple temperature monitoring task to the device using \cleaninline{liftmTask} and provides a view on its task value using the \cleaninline{>\&>} \gls{ITASK} combinator.
-%This combinator allows the observation of the left-hand side task's value through \pgls{SDS}.
-%The light switch task at \crefrange{lst:example:ls1}{lst:example:ls2} is a task that has bidirectional interaction using the definition of \cleaninline{lightswitch} shown in \cref{lst:mtask_liftsds_ex}.
-%Using \cleaninline{lowerSds}, the status of the light switch is synchronised with the user.
-%Finally, a task that calculates the factorial of a user-provided number is shown in the list.
-%
-% \vspace{4ex}
-% \begin{center}
-% \begin{subfigure}[b]{.3\linewidth}
-% \includegraphics[width=\linewidth]{home_auto1}
-% \caption{Select task.}%
-% \label{fig:example_screenshots1}
-% \end{subfigure}
-% \begin{subfigure}[b]{.3\linewidth}
-% \includegraphics[width=\linewidth]{home_auto2}
-% \caption{Select device.}%
-% \label{fig:example_screenshots2}
-% \end{subfigure}
-% \begin{subfigure}[b]{.3\linewidth}
-% \includegraphics[width=\linewidth]{home_auto3}
-% \caption{View result.}%
-% \label{fig:example_screenshots3}
-% \end{subfigure}
-% \caption{Screenshots of the home automation example program in action.}%
-% \label{fig:example_screenshots}
-% \end{center}
-% \end{leftfullpage}
-%\end{figure}
-%
-%\begin{figure}[p]
-% \begin{fullpage}
-% \cleaninputlisting[firstline=12,lastline=50,numbers=left,belowskip=0pt]{lst/example.icl}
-% \begin{lstClean}[numbers=left,firstnumber=40,aboveskip=0pt,caption={An example of a home automation program.},label={lst:example_home_automation}]
-% , ...][+\label{lst:example:tasks2}+]\end{lstClean}
-% \end{fullpage}
-%\end{figure}
+ \vspace{\headsep}
+\section{Home automation}
+This section presents an interactive home automation program (\cref{lst:example_home_automation}) to illustrate the integration of the \gls{MTASK} language and the \gls{ITASK} system.
+It consists of a web interface for the user to control which tasks are executed on either one of two connected devices: an \gls{ARDUINO} UNO, connected via a serial port; and an ESP8266 based prototyping board called NodeMCU, connected via \gls{TCP} over \gls{WIFI}.
+
+\Crefrange{lst:example:spec1}{lst:example:spec2} show the specification for the devices.
+The UNO is connected via serial using the unix filepath \path{/dev/ttyACM0} and the default serial port settings.
+The NodeMCU is connected via \gls{WIFI} and hence the \cleaninline{TCPSettings} record is used.
+Both types have \cleaninline{channelSync} instances.
+
+The code consists of an \gls{ITASK} part and several \gls{MTASK} parts.
+\Crefrange{lst:example:task1}{lst:example:task2} contains the \gls{ITASK} task that coordinates the \gls{IOT} application.
+First the devices are connected (\crefrange{lst:example:conn1}{lst:example:conn2}) followed by launching a \cleaninline{parallel} task, visualized as a tabbed window, and a shutdown button to terminate the program (\crefrange{lst:example:par1}{lst:example:par2}).
+This parallel task is the controller of the tasks that run on the edge devices.
+It contains one task that allows adding new tasks (using \cleaninline{appendTask}) and all other tasks in the process list will be \gls{MTASK} tasks once they are added by the user.
+The controller task, \cleaninline{chooseTask} as shown in \crefrange{lst:example:ct1}{lst:example:ct2}, allows the user to pick a task, and sending it to the specified device.
+Tasks are picked by index from the \cleaninline{tasks} list (\crefrange{lst:example:tasks1}{lst:example:tasks2}) using \cleaninline{enterChoice}.
+The interface that is generated for this is seen in \cref{fig:example_screenshots1}.
+After selecting the task, a device is selected (see \cref{fig:example_screenshots2,lst:example:selectdev}).
+When both a task and a device are selected, an \gls{ITASK} task is added to the process list using \cleaninline{appendTask}.
+Using the helper function \cleaninline{mkTask}, the actual task is selected from the \cleaninline{tasks} list and executed by providing it the device argument.
+For example, when selecting the \cleaninline{temperature} task, the current temperature is shown to the user (\cref{fig:example_screenshots3}).
+This task just sends a simple temperature monitoring task to the device using \cleaninline{liftmTask} and provides a view on its task value using the \cleaninline{>\&>} \gls{ITASK} combinator.
+This combinator allows the observation of the left-hand side task's value through \pgls{SDS}.
+The light switch task at \crefrange{lst:example:ls1}{lst:example:ls2} is a task that has bidirectional interaction using the definition of \cleaninline{lightswitch} shown in \cref{lst:mtask_liftsds_ex}.
+Using \cleaninline{lowerSds}, the status of the light switch is synchronised with the user.
+Finally, a task that calculates the factorial of a user-provided number is shown in the list.
+
+ \vspace{4ex}
+ \begin{center}
+ \begin{subfigure}[b]{.3\linewidth}
+ \includegraphics[width=\linewidth]{home_auto1}
+ \caption{Select task.}%
+ \label{fig:example_screenshots1}
+ \end{subfigure}
+ \begin{subfigure}[b]{.3\linewidth}
+ \includegraphics[width=\linewidth]{home_auto2}
+ \caption{Select device.}%
+ \label{fig:example_screenshots2}
+ \end{subfigure}
+ \begin{subfigure}[b]{.3\linewidth}
+ \includegraphics[width=\linewidth]{home_auto3}
+ \caption{View result.}%
+ \label{fig:example_screenshots3}
+ \end{subfigure}
+ \caption{Screenshots of the home automation example program in action.}%
+ \label{fig:example_screenshots}
+ \end{center}
+ %\end{leftfullpage}
+ \end{fullpage}
+\end{figure}
+
+\begin{figure}[p]
+ \begin{fullpage}
+ \cleaninputlisting[firstline=12,lastline=50,numbers=left,belowskip=0pt]{lst/example.icl}
+ \begin{lstClean}[numbers=left,firstnumber=40,aboveskip=0pt,caption={An example of a home automation program.},label={lst:example_home_automation}]
+ , ...][+\label{lst:example:tasks2}+]\end{lstClean}
+ \end{fullpage}
+\end{figure}
\input{subfilepostamble}
\end{document}
\end{figure}
\subsection{Byte code compiler}
-The main interpretation of the \gls{MTASK} system is the byte code compiler (\cleaninline{:: BCInterpret}).
+The main interpretation of the \gls{MTASK} system is the byte code compiler (\cleaninline{:: BCInterpret a}).
With it, and a handful of integration functions, \gls{MTASK} tasks can be executed on microcontrollers and integrated in \gls{ITASK} as if they were regular \gls{ITASK} tasks.
Furthermore, with a special language construct, \glspl{SDS} can be shared between \gls{MTASK} and \gls{ITASK} programs as well.
The integration with \gls{ITASK} is explained thoroughly later in \cref{chp:integration_with_itask}.
\end{lstlisting}
};
- \node (bc) [draw,node distance=4em,right=of src,label=above:{Byte code}] {
+ \node (bc) [draw,node distance=4em,right=of src,label=above:{byte code}] {
\scriptsize
\begin{tabular}{ll}
\verb|main:| & \ldots\\
\draw [->] (src) to node [midway,above] {compile} (bc);
\matrix (m) [node distance=4em,right=of bc,matrix of nodes,nodes in empty cells,row sep=1em] {
- Interpreter & Rewriter\\
+ interpreter & rewriter\\
\verb|main|\\
tree & tree\\
& \\
\draw [dashed]($(m-1-1.north)!0.5!(m-1-2.north)$) -- ($(m-5-1.south)!0.5!(m-5-2.south)$);
\draw [->] (m-5-2) to [out=0,in=0] (m-3-2);
- \node (dev) [draw,fit=(m),label=above:{Device}] {};
+ \node (dev) [draw,fit=(m),label=above:{device}] {};
\draw [dashed,->] (bc) to node [midway,above] {send} (dev);
-% \node (int) [block,node distance=5em,right=of bc.north] {Interpreter};
-% \node (rew) [block,node distance=1em,right=of int] {Rewrite engine};
-% \node (main) [block,node distance=.5em,below=of int] {\verb|main|};
-% \node (t1) [block,node distance=.5em,below=of main] {tree};
-% \node (t2) [block,node distance=1em,right=of t1] {tree};
-% \node (t3) [block,node distance=.5em,below=of t2] {};
-% \node (t4) [block,node distance=1em,left=of t3] {};
-% \node (t5) [block,node distance=.5em,below=of t4] {};
-% \node (t6) [block,node distance=1em,right=of t5] {};
-% \node (t7) [block,node distance=.5em,below=of t6] {tree};
-%
-% \draw [->] (main) -- (t1);
-% \draw [->] (t1) -- (t2);
-% \draw [->] (t2) -- (t3) -- (t4) -- (t5) -- (t6) -- (t7);
-% %\node (dev) [draw,fit right=of bc,label=above:{Device}] {};
\end{tikzpicture}
\end{document}
repositories / phd-thesis.git / commitdiff