# Real-Time Human Activity Recognition on Embedded Equipment: A Comparative Study
## 5 Results of Implementation
### Implementation on STM32 and ESP32 with C Language  
The objective of this section is to study the performances of the algorithm implemented in C programming language on STM32-NUCLEO H753 ZIT6 and on Espressif ESP32 microcontrollers. Table 11 presents the processing time and the used memory. The objective is to study the performance for the long activity period (Sleeping in this work). Table 11 provides the results of experiments. Figure 10: Processing Time evolution in STM32 MCU over a maximum number of records. Figure 9: Processing Time evolution in STM32 MCU over a maximum number of records: use of MP programming language. From experimental results, the following conclusions can be drawn:  
* _Processing time_--ESP32 performs better in terms of processing time compared to STM32. The algorithm executes in approximately half the time on the ESP32 (0.0022 s) compared to STM32 (0.004018 s). The C implementation generally shows shorter processing times compared to MicroPython on both STM32 and ESP32. The C implementation on ESP32 still has a shorter processing time (0.0022 s) compared to MicroPython on ESP32 (0.15 s). * _Memory usage_--The C implementation uses specific memory categories like Flash Memory, RAM D1, static DRAM, and static IRAM. MicroPython uses a unified measure of memory in octets (bytes). However, based on the provided information, the memory usage is similar for both STM32 and ESP32 in C and MicroPython implementations (around 9232 bytes). * _Performance considerations_--When comparing the processing time related to sampling, segmentation, and classification on STM32 and ESP32 microcontrollers, we have observed that the processing time meets the required constraint. However, we experienced memory failures when exceeding a certain number of data records. In terms of processing time, the C implementation generally outperforms MicroPython in this specific use case. Memory usage is similar between the two implementations, indicating that the specific language used (C or MicroPython) might not have a significant impact on memory requirements. Additionally, we noted a difference in memory capacity when coding in C compared to MicroPython on STM32. These observations could be explained by:  
* The fact that the processing time meets the required constraint is a positive outcome. It indicates that the microcontrollers are capable of handling the processing tasks within the specified time frame. In addition, it is important to assess the consistency of the processing time under different conditions. If the processing time remains within the desired range across various scenarios, it suggests stability and reliability in the system. * Another important point is the memory capacity difference between C and MicroPython. In fact, this difference is not uncommon. It can be explained by the fact that MicroPython, being a higher-level language, might introduce additional overhead for features such as garbage collector and dynamic typing, potentially leading to increased memory usage. Also, regarding optimization, when working in C, we have more direct control over memory management and optimizations. Moreover, we can fine-tune the code for efficiency, which may result in lower memory usage compared to a higher-level language like MicroPython. In addition, coding in C provides hardware-specific libraries to simplify tasks related to controlling peripherals such as turning on an LED when starting the computation of processing time related to a specific task. Since there are no particular project constraints, we can perhaps make a compromise between ease of development (using a higher-level language) and resource efficiency. \begin{table}
\begin{tabular}{c c c} \hline \hline  & **STM32** & **ESP32** \\ \hline Processing time & 0.004018 s & 0.0022 s \\ \hline \multirow{3}{*}{Memory} & 68.98 kB Flash (3.37\% usage) & Used static DRAM = 12,896 bytes \\  & 6.5 KB RAM D1 (1.27\% usage) & Used static IRAM = 48,776 bytes \\ \hline \hline \end{tabular}
\end{table}