6.2.2. Step 2: Execute the Application. Altium TriCore
Реклама
Реклама
Profiling
Function timers (not in combination with Block counters)
This will instrument the code to measure the time spent in a function. This includes the time spent in all called functions (callees).
For the command line, see the
C compiler option --profile (-p)
.
Profiling is only possible with optimization levels 0, 1 and 2. So:
5.
Open the Optimization page and set the Optimization level to 2 - Optimize more.
6.
Click OK to apply the new option settings and rebuild the project ( ).
6.2.1.1. Profiling Modules and C Libraries
Profiling individual modules
It is possible to profile individual C modules. In this case only limited profiling data is gathered for the functions in the modules compiled without the profiling option. When you use the suboption Call graph, the profiling data reveals which profiled functions are called by non-profiled functions. The profiling data does not show how often and from where the non-profiled functions themselves are called. Though this does not affect the flat profile, it might reduce the usefulness of the call graph.
Profiling C library functions
Eclipse and/or the control program will link your program with the standard version of the C library.
Functions from this library which are used in your application, will not be profiled. If you do want to incorporate the library functions in the profile, you must set the appropriate C compiler options in the C library makefiles and rebuild the library.
6.2.1.2. Linking Profiling Libraries
When building your application, the application must be linked against the corresponding profile library.
Eclipse (or the control program) automatically select the correct library based on the profiling options you specified. However, if you compile, assemble and link your application manually, make sure you specify the correct library.
See Section 8.3, Linking with Libraries
for an overview of the (profiling) libraries.
6.2.2. Step 2: Execute the Application
Once you have compiled and linked the application for profiling, it must be executed to generate the profiling data. Run the program as usual: the program should run normally taking the same input as usual and producing the same output as usual. The application will run somewhat slower than normal because of the extra time spent on collecting the profiling data.
Eclipse has already made a default simulator debug configuration for your project. Follow the steps below to run the application on the TASKING simulator, using the debugger. (In fact, you can run the application also on a target board.)
1.
From the Run menu, select Debug...
207
TASKING VX-toolset for TriCore User Guide
The Create, manage and run configurations dialog appears.
2.
Select the simulator debug configuration (TASKING Embedded C/C++ Application »
profiling.simulator).
3.
Click the Debug button to start the debugger and launch the profiling application.
Eclipse will open the TASKING Debug perspective (as specified in the configuration) and asks for confirmation.
4.
Click Yes to open the TASKING Debug perspective.
The TASKING Debug perspective opens while the application has stopped before it enters main()
5.
In the Debug view, click on the (Resume) button.
A file system simulation (FSS) view appears in which the application outputs the results.
When the program has finished, the collected profiling data is saved (for details see 'After execution' below).
Startup code
The startup code initializes the profiling functions by calling the function
__prof_init()
. Eclipse will automatically make the required modifications to the startup code. Or, when you use the control program, this extracts the correct startup code from the C library.
If you use your own startup code, you must manually insert a call to the function
__prof_init
just before the call to main
and its stack setup.
An application can have multiple entry points, such as main()
and other functions that are called by interrupt. This does not affect the profiling process.
Small heap problem
When the program does not run as usual, this is typically caused by a shortage of heap space. In this case a message is issued (when running with file system simulation, it is displayed on the Debug console).
To solve this problem, increase the size of the heap. Information about the heap is stored in the linker script file (.lsl) file which is automatically added when a project is created.
1. In the C/C++ view, expand the project tree and double-click on the file profiling.lsl
to open it.
In the editor view, the LSL file is opened, showing a number of tabs at the bottom.
2. Open the Stack/Heap tab and enter a larger value for heap.
3. Save the file.
Presumable incorrect call graph
The call graph is based on the compiled source code. Due to compiler optimizations the call graph may therefor seem incorrect at first sight. For example, the compiler can replace a function call immediately
208
Изтегляне
Реклама