# Modeling the Power Consumption of Function-Level Code Relocation for Low-Power Embedded Systems
## 3 Configuration of Entire Environment
### Power Measurement  
The MSP432P401R Launchpad, which is used to measure power, was also designed by TI. The processor is the same as the Launchpad used in Section 3.1 and has a heterogeneous memory component, 256 KB Flash memory, and 64 KB SRAM, which can be used to implement function-level code relocation. Moreover, unlike other microcontrollers, this is specifically designed for low-power operation. In particular, the EnergyTrace+ hardware, which enables the implementation of the EnergyTraceTM technique used to generate the estimated measurement summaries, such as the amount of power consumed, the amount of energy used, and the life of the battery, is included. The primary factor of the measurement is power consumption while implementing a low-power embedded system is the ultimate objective. Any electrical signal such as power relies on the ambient environment. Thus, all connections in the Launchpad except for the essential components are separated to allow precise measurement.  
When using instruction trace, i.e., as described in Section 3.1 and power measurement, as explained in Section 3.2, the environments used differ in several respects. The MSP432E401Y Launchpad used for instruction trace supports the creation of programs using Keil uVision5 to trace instructions through the ARM CC compiler. Meanwhile, the MSP432P401R Launchpad, which is used for power measurements, supports the creation of programs that use the TI compiler to measure power consumption using Code Composer Studio (CCS). However, both MCUs are designed with the ARM Cortex-M4F microprocessor based on the same ARM instruction set. This indicates that the instruction trace description, which is the result of the instruction trace, is correlated with the measurement summary, which is the power measurement result. Figure 4 presents a further comparison of the executed codes.  
\begin{table}
\begin{tabular}{l c c} \hline \hline _Instruction Group_ & _Redefined Instruction Group_ & _Example_ \\ \hline Data Processing & DP Group & ADDS, SUB, ORR, MOV,... \\ \hline Register Load and Store & RLS Group & LDR, STR, PLD, SWP,... \\ \hline Multiple Register Load and Store & & LDM, STM, PUSH, POP,... \\ \hline Branch and Control & BC Group & B, BL, BX, BLX,... \\ \hline Status Register Access & Not Considered & MRS, MSR, CPS, SETEND,... \\ \hline Coprocessor & Not Considered & CDP, MCR, MRC, LDC,... \\ \hline \hline \end{tabular}
\end{table}
Table 2: Group of ARM instruction set.  
The disassembly window captured from each environment implies the execution of each respective sample of programming language shown in Figure 4. As shown, the instructions included in these samples are highly comparable, despite the environments using different compilers. While the two compilation environments differ in numerous ways, such as the type of registers or expressed syntax, an important factor affecting the description of instruction trace is the type of operation the instruction performs, e.g., MOVS, ADDS, LDR, and STR. Additionally, the number of instructions from each group of instructions is the same, even if the environment used is different. Hence, concerns about the inability to maintain consistency that may arise from the use of different environments can be eliminated. In other words, extraction of the instruction trace description from the instruction trace environment and analyzing the power summary results in the power measurement environment are valid forms of analysis.