# A Modular IoT Hardware Platform for Distributed and Secured Extreme Edge Computing
## 2 Modular Hardware Platform for the Extreme Edge of IoT
### Characterization  
From a hardware perspective, this work is heavily focused on sensor nodes for the IoT, and not on the general wireless sensor networks domain. For this reason, it might not cover some of the most popular and traditional devices of the literature and include some others that better fit within the scope of next generation IoT Edge devices, as commented before. Also, it will not compare the proposed platform to smaller 8-bit or 16-bit-based platforms, since the performance and overall purpose of those differ from the aim of the proposed Extreme Edge platform.  
To study the different low-power modes, every single combination of the state of the power islands has been tested on the Cookie Edge Node, going through all the energy modes of the processor for each one of them. The main approach was also to test the upper boundaries of the power profile sets in order to provide a trade-off relationship between power consumption and platform performance, seeking a good balance for those more demanding IoT scenarios, as described in the introduction section. The procedure started by initializing the board and forcefully staying in EM0 mode for a few seconds. After that, the MCU went into the next mode (EM1 - sleep) and waited for another 3 s, repeating this process successively from the highest to the lowest power mode. Before going into deep sleep mode (EM2), a low frequency clock was prepared to wake up the MCU and proceed into the next instruction.  
During the tests, the peripherals in their enabled state were in idle mode waiting for the instruction to start a sensing cycle, and did not perform any operation or measure. In this way, the measurements obtained are closer to a real behavior since the sensing frequency in a real deployment is supposed to be low, i.e., the purpose of the low-power modes is to save energy when the board is idle, not during a measurement/transmission cycle.  
The consumption of each one of the combined low-power modes can be seen in Table 2.  
Table 3 shows the approximate current consumption of different platforms in their active state (MCU active, peripherals enabled) and their idle state (MCU sleeping, peripherals turned off). The platforms featured are OpenMoteB (CC2538 SoC based on ARM Cortex-M3, 32-bit), DotNOW emote (STM32F103 ZG [18] ARM Cortex-M3, 32-bit) and Sparkfun freeSoC2 [19] (PSoC5 LP ARM Cortex-M3, 32-bit). The consumption values shown for the platforms are taken from their respective datasheets, obtained by adding the manufacturer values for the processor consumption in similar circumstances than those of the Cookie for its testing: MCU active with the radio turned off and peripherals enabled but in a wait state. The values for the stm32 consumption (DotNOW emote) that correspond to sleep mode at 36 MHz with all peripherals enabled are shown. The consumption of OpenMoteB was obtained by adding 13 mA of core consumption at 32 MHz and the consumption of some common peripherals: GP timer, USB, SPI, I\({}^{2}\)C, UART, but no ADC nor Flash being used. Consumption values for the freeSoC2 were obtained directly from the datasheet for a frequency of 24/48 MHz and 25 \({}^{\circ}\)C.  
\begin{table}
\begin{tabular}{l c c c} \hline \hline  & **EM0** & **EM1** & **EM2** \\ \hline All islands disabled & 11.93 & 10.43 & 6.80 \\ Temp sensor enabled & 11.94 & 10.44 & 6.81 \\ Cryptchip enabled & 11.99 & 10.45 & 6.82 \\ Inertial sensor enabled & 12.44 & 10.89 & 7.33 \\ Temp + Crypto enabled & 11.99 & 10.45 & 6.83 \\ Temp + Inertial enabled & 12.51 & 10.87 & 7.34 \\ Crypto + Inertial enabled & 12.45 & 10.95 & 7.35 \\ All islands enabled & 12.52 & 10.97 & 7.37 \\ \hline \hline \end{tabular}
\end{table}
Table 2: Current consumption of the combined low-power modes for the upper active consumption states (mA).