# Two Designs of Automatic Embedded System Energy Consumption Measuring Platforms Using GPIO
## 2 Related Works and Motivations
### Problems  
The abovementioned works have provided a variety of power consumption measurements and modeling methods for embedded systems, but some problems remain to be solved. In many studies, researchers have focused largely on power consumption, paying more attention to changes in power consumption when applications, devices, or radios were running, in order to investigate the runtimes of operations with a high-power consumption in embedded systems and predict or estimate the overall battery life.  
However, energy consumption is an accumulation, representing the time integral of power. The more detailed performance of hardware design, code optimization, and energy analysis requires an understanding of the impact of time on energy consumption. In the research mentioned in the previous subsection related to modeling and measurement, many did not consider \"time\". In [19; 27; 28; 29; 31; 33; 34; 36], the granularity of time was in seconds, whereas in [1; 3; 5; 6; 8; 9], time was calculated per unit of battery discharge. This is no problem for most applications and radios that take tens of milliseconds or seconds to execute, but the determination of the energy consumed by small code segments that constitute the applications requires more precise timestamps to mark the execution time, which is usually only tens of microseconds. To retrieve high-precision timestamps, researchers used environment variables [11], library functions [42], or event-driven system call tracing [12; 14; 20; 29; 43; 44; 45; 46] to log or mark precise timestamps. In general, the accuracy of a timestamp or timer provided by an operating system is in milliseconds. Millisecond accuracy may be applicable for measuring the execution time of the entire application, but it cannot measure the execution time of the functions in the application or the code segments that constitute the application. Some researchers also used library functions or environment variables to record the execution time; unfortunately, these library functions and environment variables only provide precision, not accuracy, and do not guarantee the frequency of value changes [47; 48]. We conducted our own verification and the results are listed in Table 1. The results showed that the frequency of value changes was quite variable; therefore, the use of system calls, library functions, or environment variables to mark timestamps was deemed to be unacceptable.  
It was stated in [12; 14; 18] that directly sampling power consumption data at a high frequency using embedded systems impacted the performance and resulted in distorted measurement results; thus, power consumption data should be sampled and collected outside the embedded systems. Since timestamps are obtained using embedded systems and power consumption data are collected by a power meter on another device, this introduces the problem of time synchronization. The connection between the code execution process and the power consumption data cannot be effectively established if the obtained timestamp and the collected power consumption data are not properly synchronized.