A processor like the ESP8266 driving the \gls{WEMOS} D1 mini loses the content of its \gls{RAM} in deep sleep mode.
As a result, after waking up, the program itself is preserved, since it is stored in flash memory, but the program state is lost.
When there is a program state to be preserved, we must either store it elsewhere, limit us to light sleep, or use a microcontroller that keeps the \gls{RAM} intact during deep sleep.
+\todo[inline]{Na de voorgaande hoofdstukken kun je dit makkelijk expliciet maken voor mtask.
+For mTasks this implies that the mTask OS is preserved during deep sleep, but all shipped tasks and their states will be lost.}
For edge devices executing a single task, explicit sleeping to save energy can be achieved without too much hassle.
This becomes much more challenging as soon as multiple independent tasks run on the same device.
Reading \glspl{SDS} and measuring fast sensors such as sound or light aim for a rewrite every \qty{100}{\ms}.
Medium slow sensors such as gesture sensors are expected to rewrite every \qty{1000}{\ms}.
Slow sensors such as temperature or air quality have an upper bound of \qty{2000}{\ms}.
+In \cref{sec:tweak_rewrite} we show how the programmer can tweak these rewrite rates to match specific needs.
\begin{table}
\centering
In case of the \cleaninline{rpeat} task, the default refresh rate is $\rewriterate{0}{0}$ so the task immediately refreshes and starts the task again.
\subsubsection{Delay combinators}
-Upon installation, a \cleaninline{delay} task is stored as a \cleaninline{waitUntil} task tree containing the time of installation added to the specified time to wait.
+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.
\subsubsection{Other tasks}
\end{tabular}
\end{table}
-\subsection{Tweaking rewrite rates}
+\subsection{Tweaking rewrite rates}\label{sec:tweak_rewrite}
A tailor-made \gls{ADT} (see \cref{lst:interval}) is used to tweak the timing intervals.
The value is determined at runtime, but the constructor is known at compile time.
During compilation, the constructor of the \gls{ADT} is checked and code is generated accordingly.
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}
+\todo[inline]{
+Ik zou hier een klein algemeen verhaal over interrupts schrijven om te zorgen dat de lezer weet waarom dit de moeite van het lezen waard is. B.v.
+An interrupt is a request for the processor to interrupt the currently exected code or its sleep, to handle the event. It is typically much more energy efficient and accurate when a sensor interrupts the processor to notify that something interresting is happening than when the processor repeatedly checks that sensor's state.
+}
Most microcontrollers have built-in support for processor interrupts.
These interrupts are hard-wired signals that interrupts the normal flow of the program 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.
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.
+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.
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}.
repositories / phd-thesis.git / blobdiff