Program optimization using an in-circuit emulator (ICE)

At present, In Circuit Emulator (ICE) is used by more and more engineers in embedded system development. Especially in foreign embedded development companies, ICE is a necessary debugging tool and is widely used to improve the efficiency of development and debugging. However, in China, due to debugging habits and development costs, emulators are more often used in the debugging stage of the underlying driver in the early stage of product development. When the performance of the product is relatively stable, engineers often use serial port debugging methods to debug the application.

Compared with emulator debugging, serial port debugging is simpler and the human-computer interaction function is not friendly enough. When encountering complex program errors, development efficiency may be greatly reduced. A powerful ICE can often provide a wealth of debugging methods to make debugging work more efficient. Only users can deeply appreciate the convenience and efficiency that ICE brings to embedded debugging.

There are many types of ICEs on the market, and their functions are also very different. Many simulators can only provide basic debugging functions, such as setting breakpoints, observing system resources, etc. Some advanced functions, such as the Embedded Trace Macrocell (ETM) tracing function, are only available in some high-end simulators, and of course the price is much higher than that of general simulators. This article mainly introduces some applications of using ICE in program optimization, which requires the use of some advanced functions.

Function 1: Measurement of the running time between any two statements

When you have written a piece of code and want to calculate the running time of this code to provide a basis for code optimization, how can you accurately measure this period of time?

If you don't have an emulator, there are two methods you can use:

1. Manual timing, start timing with a watch when the code is executed, and stop timing when the code is finished. This method has a large error and is obviously not able to meet the requirements for code segments that only take a few microseconds or even less to execute.

2. Add a timing function to the code. This method has a certain degree of accuracy, but it will increase the complexity of the code, and the timing results need to be printed out.

If you use an ICE emulator, this task becomes very simple. Take Yokogawa's advicePRO as an example. In its built-in debugging software microVIEW-PLUS (hereinafter referred to as MVP), you don't need to look at the watch or modify the code. You can easily get the running time of this code by setting breakpoints at both ends of the code, and the accuracy can reach 20ns. As shown in Figure 1, when executing to the first breakpoint b1, clear the time in the window status bar, and then execute the code. When the program stops at the second breakpoint b2, the execution time of this code will be accurately displayed in the status bar.

Figure 1: Setting a breakpoint to measure the runtime between two statements.

Function 2: Multiple measurement and analysis of the running time between two statements

For the same piece of code, the running time may vary greatly due to different running conditions. How to count the running time of a piece of code to truly achieve the purpose of performance analysis?

When using the simulator, you can repeat the measurement function in "Optimization Function 1" to perform manual statistics. However, the disadvantage of doing so is that it is time-consuming and labor-intensive, and it cannot truly reflect the status of the program when it is running in real time.

ICE simulators with ETM tracing function can provide a simple measurement function, which can continuously measure the time of the program for a specified number of times and automatically perform time statistics. However, not all simulators with ETM tracing function have such a function. The following still takes Yokogawa's advicePRO as an example to introduce the use of this function. The specific measurement steps are as follows:

1. Set the start and end event points in the program segment: Event refers to various activities that can be detected during the execution of the program. For example, the execution of a statement at a function or address, the reading and writing of data at an address, and even the monitored external trigger signal can be defined as an event as the start or end condition of the tracking function and time measurement. Figure 2 shows that the fetch state of line 184 of a source code file is set as event e0 through the setting window. Assuming that the running time of lines 184 to 191 in the for loop in the LCD_test.c file is to be measured, two events e0 and e1 are set at lines 184 and 191 according to the method in Figure 2. (See Figure 3)

Figure 2: Setting the starting point of the source code file in the Settings window.

Figure 3: The MVP window after setting the start and end points in the program file.

2. Set external output conditions: Set e0 and e1 as external output conditions, as shown in Figure 4.

Figure 4: Setting external output conditions.

3. Set measurement conditions: In the window shown in Figure 5, set e0 and e1 as the start and end points of time measurement, and set the measurement mode. You can perform measurement statistics for times exceeding or within the specified time.

Figure 5: Set the start and end points of the time measurement and set the measurement mode.

4. Run the program: After making the above settings, you can run the program to measure the time.

5. Display of measurement results: After the measurement is completed, the measurement results will be automatically displayed in the report window in the form of a chart, and the longest, shortest and average running time will be displayed. (See Figure 6) Through this chart, users can clearly understand the running time distribution of this code, providing the most direct basis for code optimization.

Figure 6: The measurement results are displayed in a graph, providing a clear understanding of the runtime distribution of the code.

Function 3: Measuring code coverage

Code coverage refers to the percentage of statements executed in a code segment. It is an important indicator for measuring code quality and is often used in code testing. Testing code coverage in PC applications is not a difficult task, but it is more difficult to measure in the real-time environment of embedded systems.

Yokogawa's advicePLUS simulator provides such an extended function, making it easy to measure code coverage in an embedded environment. The setting method is very simple. Just give the start and end addresses of the code segment to be tested, or give the name of the function to be tested in the corresponding setting window of MVP. (See Figure 7)

Figure 7: Code coverage analysis in MVP.

After the program is finished running, the code coverage will also be displayed in the result window in the form of a chart. (See Figure 8) The code execution status of each function can be clearly seen from the chart.

For example, if the code coverage of the function Strcpy() is 0, it means that this function has not been executed. For programmers, it is necessary to consider whether this function is necessary. For functions with very low coverage, it is necessary to consider whether this function needs to be incorporated into other functions.

Figure 8: Code coverage displayed as a graph.

Not only can code coverage be measured, but data coverage within a certain address range can also be measured in a similar way. This function allows users to easily grasp the usage information of the data area. (See Figure 9)

Figure 9: Testing data coverage within a specified address range.

It is not an easy task to optimize programs in embedded development. The functions provided by the ICE emulator can make program optimization simple and allow programmers to configure system resources more effectively.

It should be noted that not all ICE emulators can provide these functions. Choosing a powerful emulator can not only improve the development efficiency for developers, but also help developers improve the code quality and make the enterprise products run more stably and reliably.