It is therefore crucial to lower their energy consumption.
To reduce the power consumption of an \gls{IOT} edge device, the specialised low-power sleep modes of the microprocessors can be leveraged.
-Different sleep mode achieve different power reductions because of their run time characteristics.
+Different sleep modes achieve different power reductions because of their run time characteristics.
These specifics range from disabling or suspending the \gls{WIFI} radio; stop powering (parts) of the \gls{RAM}; disabling peripherals; or even turning off the processor completely, requiring an external signal to wake up again.
Determining exactly when, and for how long it is safe to sleep is expensive in the general case.
In practise, it means that either annotations in the source code, a \gls{RTOS}, or a scheduler is required.
During rewriting, each step, tasks do a bit of their work and progress steadily, allowing interleaved and seemingly parallel operation.
Atomic blocks, such as \gls{IO}, are always contained within a rewrite step.
This is very convenient, since the system can inspect the current state of all \gls{MTASK} expressions after a rewrite and decide if sleeping and how long is possible.
-After each loop, the \gls{RTS} knows which task is waiting on which triggers and is thus determines when it is possible and safe to sleep and choose the optimal sleep mode according to the sleeping time.
+After each loop, the \gls{RTS} knows which task is waiting on which triggers.
+With this information, the system determines when it is possible and safe to sleep, and chooses the optimal sleep mode according to the sleeping time.
%As a consequence, we cannot have fair multitasking.
%When a single rewrite step would take forever due to an infinite sequence of function calls, this would block the entire \gls{IOT} node.
%Even infinite sequences rewrite steps are perfectly fine.
%The \gls{MTASK} system does proper tail-call optimisations to facilitate this.
\section{Rewrite interval}
-Some \gls{MTASK} programs contain one or more explicit \cleaninline{delay} primitives, offering a natural place a pause.
+Some \gls{MTASK} programs contain one or more explicit \cleaninline{delay} primitives, offering a natural pause.
However, there are many \gls{MTASK} programs that just specify a repeated set of primitives.
A typical example is the program that reads the temperature for a sensor and sets the system \gls{LED} if the reading is below some given \cleaninline{goal}.
\subsection{Basic tasks}
We start by assigning default rewrite rates to basic tasks.
These rewrite rates reflect the expected change rates of sensors and other inputs.
-Basic tasks to set a value of a sensor or actuator have a rate of $\rewriterate{0}{0}$, this is never delayed.
+Basic tasks to set a value of a sensor or actuator have a rate of $\rewriterate{0}{0}$, i.e.\ this is never delayed.
An example of such a one-shot task in the task that writes to a \gls{GPIO} pin.
Basic tasks that continuously read a sensor or otherwise interact with a peripheral have default rewrite rates that fit standard usage of the sensor.
\Cref{tbl:rewrite} shows the default values for the basic tasks.
\left\{\begin{array}{ll}
\mathcal{R}(t) & \text{if $t$ is unstable}\\
\rewriterate{r_1-\mathit{start}}{r_2-\mathit{start}} & \text{otherwise}\\
+ & \text{\bf where } \mathcal{R}(t) = \rewriterate{r_1}{r_2}\\
\end{array}\right.\\
\mathcal{R} (\mathit{waitUntil}~d) & = \rewriterate{e-\mathit{time}}{e-\mathit{time}}\label{R:delay}\\
\mathcal{R} (t) & =
\begin{equ}
\[
X \cap_{\textit{safe}} Y = \left\{%
- \begin{array}{ll}
+ \begin{array}{lll}
X\cap Y & X\cap Y \neq \emptyset\\
- Y & Y_2 < X_1\\
+ Y & Y_2 < X_1 & \text{\bf where } Y = \rewriterate{Y_1}{Y_2} \text{ and } X = \rewriterate{X_1}{X_2}\\
X & \text{otherwise}\\
\end{array}
\right.
\subsubsection{Delay combinators}
Upon installation, a \cleaninline{delay} task is stored as a \cleaninline{waitUntil} task, containing the time of installation added to the specified time to wait.
-Execution wise, it waits until the current time exceeds the time is greater than the argument time.
+Execution wise, it waits until the current time exceeds the time the argument time.
\subsubsection{Other tasks}
All other tasks are captured by \cref{R:other}.
\subsection{Example}
The rewrite intervals associated with various steps of the thermostat program from \cref{lst:thermostat} are given in \cref{tbl:intervals}.
-The rewrite steps and intervals are circular, after step 2 we continue with step 0 again.
+The rewrite steps and intervals are circular.
+After step 2 we continue with step 0 again.
Only the actual reading of the sensor with \cleaninline{temperature dht} offers the possibility for a non-zero delay.
%%\begin{table}[tb]
\section{Task scheduling in the mTask engine}\label{sec:scheduling}
The rewrite rates from the previous section only tell us how much the next evaluation of the task can be delayed.
-In the \gls{MTASK} system, an \gls{IOT} edge devices can run multiple tasks.
+In the \gls{MTASK} system, an \gls{IOT} edge device can run multiple tasks.
In addition, it has to communicate with a server to collect new tasks and updates of \glspl{SDS}.
Hence, the rewrite intervals cannot be used directly to let the microcontroller sleep, so a scheduler is involved.
Our scheduler has the following objectives.
This is achieved by adding the start time of this round of task evaluations rather than the current time to compute absolute execution intervals.
\subsection{Scheduling Tasks}
-Apart from the task to execute, the device maintains the connection with the server and check there for new tasks and updates of \gls{SDS}.
+Apart from the task to execute, the device maintains the connection with the server and checks there for new tasks and updates of \gls{SDS}.
When the microcontroller is active, the connection is checked and updates from the server are processed.
After that, the tasks that are within the execution window are executed.
Next, the microcontroller goes to light sleep for the minimum of a predefined interval and the task delay.
In general, the microcontroller executes multiple \gls{MTASK} tasks at the same time.
-The \gls{MTASK} device repeatedly check for inputs from the server and executes all tasks that cannot be delayed to the next evaluation round one step.
-The tasks are stored in a priority queue to check efficiently which of them need to be stepped.
+The \gls{MTASK} device repeatedly checks for inputs from the server and executes all tasks that cannot be delayed to the next evaluation round one step.
+The tasks are stored in a priority queue to check efficiently which of them need stepping.
The \gls{MTASK} tasks are ordered at their latest start time in this queue; earliest deadline first.
We use the earliest deadline to order tasks with equal latest deadline.
We use a simple heuristic to evaluate tasks and determine sleep time rather than wasting energy on a fancy evaluation algorithm.
\Cref{lst:evalutionRound} gives this algorithm in pseudo code.
First the edge device checks for new tasks and updates of \glspl{SDS}.
-This communication adds the new task to the queue, if there where any.
+This communication adds the new task to the queue, if there were any.
The \cleaninline{stepped} set contains all tasks evaluated in this evaluation round.
Next, we evaluate tasks from the queue until we encounter a task that has an evaluation interval that has not started.
This may result in evaluating tasks earlier than required, but maximises the opportunities to sleep after this evaluation round.
%Using the \prog{stepped} set ensures that we evaluate each task at most once during an evaluation round.
-Executed tasks are temporarily stored in the \cleaninline{stepped} set instead of inserted directly into the queue to ensure that they are evaluated at most once in a evaluation round to ensure that there is frequent communication with the server.
+Executed tasks are temporarily stored in the \cleaninline{stepped} set instead of inserted directly into the queue to ensure that they are evaluated at most once in an evaluation round to ensure that there is frequent communication with the server.
A task that produces a stable value is completed and is not queued again.
\begin{algorithm}
The \cleaninline{sleep} function determines the maximum sleep time based on the top of the queue.
The computed sleep time and the characteristics of the microprocessor determine the length and depth of the sleep.
-For very short sleep times it is not be worthwhile to put the processor in sleep mode.
+For very short sleep times it is not worthwhile to put the processor in sleep mode.
In the current \gls{MTASK} \gls{RTS}, the thresholds are determined by experimentation but can be tuned by the programmer.
On systems that lose the content of their \gls{RAM} it is not possible to go to deep sleep mode.
\section{Interrupts}\label{lst:interrupts}
Most microcontrollers have built-in support for processor interrupts.
-These interrupts are hard-wired signals that interrupts the normal flow of the program or sleep state in order to execute a small piece of code, the \gls{ISR}.
+These interrupts are hard-wired signals that interrupt the normal flow of the program or sleep state in order to execute a small piece of code, the \gls{ISR}.
While the \glspl{ISR} look like regular functions, they do come with some limitations.
For example, they must be very short, in order not to miss future interrupts; can only do very limited \gls{IO}; cannot reliably check the clock; and they operate in their own stack, and thus communication must happen via global variables.
After the execution of the \gls{ISR}, the normal program flow is resumed.
Interrupts are heavily used internally in the firmware of microcontrollers to perform timing critical operations such as \gls{WIFI}, \gls{I2C}, or \gls{SPI} communication; completed \gls{ADC} conversions; software timers; exception handling; \etc.
-Using interrupts in \gls{MTASK} task offer two substantial benefits: fewer missed events and better energy usage.
+Using interrupts in an \gls{MTASK} task offer two substantial benefits: fewer missed events and better energy usage.
Sometimes an external event such as a button press only occurs for a small duration, making it possible to miss it due to it happening right between two polls.
Using interrupts is not a fool-proof way of never missing an event.
Events could still be missed if they occur during the execution of an \gls{ISR} or while the microcontroller was in the process of waking up from a triggered interrupt.
As buttons sometimes induce noise shortly after pressing, events within \qty{30}{\ms} after pressing are ignored.
In between the button presses, the device goes into deep sleep using the \arduinoinline{LowPower} library to handle the processor specific sleep interface.
-\Crefrange{lst:arduino_interrupt:defs_fro}{lst:arduino_interrupt:defs_to} defines the pin and debounce constants.
+\Crefrange{lst:arduino_interrupt:defs_fro}{lst:arduino_interrupt:defs_to} define the pin and debounce constants.
\Cref{lst:arduino_interrupt:state} defines the current state of the \gls{LED}, it is declared \arduinoinline{volatile} to exempt it from compiler optimisations because it is accessed in the interrupt handler.
\Cref{lst:arduino_interrupt:cooldown} flags whether the program is in debounce state, i.e.\ events should be ignored for a short period of time.
Moreover, an exception is thrown if multiple types of interrupts are registered on the same pin.
\subsubsection{Triggering interrupts}
-Once an interrupt fires, tasks registered to that interrupt are not immediately evaluated because it is usually not safe to do.
+Once an interrupt fires, tasks registered to that interrupt are not immediately evaluated because it is usually not safe.
For example, the interrupt could fire in the middle of a garbage collection process, resulting in corrupt memory.
-Furthermore, to insure the \gls{ISR} to be very short, just a flag in the event administration is set to be processed later.
+Furthermore, to ensure the \gls{ISR} to be very short, just a flag in the event administration is set to be processed later.
Interrupt event flags are processed at the beginning of the event loop, before tasks are executed.
For each subscribed task, the task tree is searched for nodes listening for the particular interrupt.
When found, the node is flagged and the pin status is written.
The interrupt can be disabled as all tasks waiting for the interrupt become stable after firing.
More occurrences of the interrupts do not change the value of the task as stable tasks keep the same value forever.
Therefore, it is no longer necessary to keep the interrupt enabled, and it is relatively cheap to enable it again if needed in the future.
-Evaluating interrupt task node in the task tree is trivial because all the work was already done when the interrupt was triggered.
+Evaluating an interrupt task node in the task tree is trivial because all the work was already done when the interrupt was triggered.
The task emits the status of the pin as a stable value if the information in the task shows that it was triggered.
Otherwise, no value is emitted.
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 (see \citep{crooijmans_reducing_2022}).
-Those reductions are a necessity for edge devices running of battery power.
+Our examples show a reduction in energy consumption of two orders of magnitude (see \citep*{crooijmans_reducing_2022}).
+Those reductions are a necessity for edge devices running on battery power.
Given the exploding number of \gls{IOT} edge devices, such savings are also mandatory for other devices to limit the total power consumption of the \gls{IOT}.
\input{subfilepostamble}
repositories / phd-thesis.git / blobdiff