many updates, fix everything up to 6.5
[phd-thesis.git] / top / green.tex
index f228ab1..e86f0b2 100644 (file)
@@ -68,6 +68,7 @@ A deeper sleep mode saves more energy, but also requires more work to restore th
 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.
+For mTasks this implies that the \gls{MTASK} \gls{RTS} is preserved during deep sleep, but all shipped tasks and their states are 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.
@@ -133,6 +134,7 @@ Basic tasks that continuously read a sensor or otherwise interact with a periphe
 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
@@ -210,7 +212,7 @@ Otherwise, the refresh rate is the embedded rate time minus the start time.
 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}
@@ -260,7 +262,7 @@ rpeat ( temperature dht >>~. \temp.
        \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.
@@ -449,7 +451,7 @@ On systems that lose the content of their \gls{RAM} it is not possible to go to
 
 \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 in order to execute a small piece of code, the \gls{ISR}.
+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}.
 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.
@@ -603,7 +605,7 @@ Furthermore, the execution intervals offer an elegant and efficient way to add i
 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}.