Hello praktikant2fs3551.scw@zf.com,
The clock source for the profiler is actually SPLL/4, so 20MHz. So if you want to convert from profiling cycles (LPIT cycles) to core clock cycles, you can multiply by 4 the value that you get from the profiler block.
If you want to convert from profiling cycles to microseconds, you can divide by value (in MHz) and then divide by 4 (because it’s 4 times slower than the core).
e.g.: Let’s say we have a simple function for which the profiler returns the value 22 cycles. In this scenario we have core frequency = 80MHz.
22 cycles / 80 MHz / 4 = ~0.069 us. If we’d had 112MHz core speed selected, it would have taken 22 cycles / 112MHz / 4 = ~0.049us.
For this example, it takes 22 * 4 = 88 CPU cycles.
Tested on your example, I got the following values:
- 88469 profiler (PIT) bus clock ticks - for 1 subsystem (1 for loop) - 88469 / 80 / 4 = ~276us
- 177736 profiler (PIT) bus clock ticks - for 2 subsystems (2 for loops) - 177736 / 80 / 4 = ~555.4us
What you'll have to know for using the profiler block is that in some cases you'll have to set the subsystem as an atomic unit. You can do this by right clicking the subsystem you want to profile, click on Block parameters and from there select (in the Main tab) "Treat as atomic unit" + from Code generation tab "Function packaging: Reusable function" (or nonreusable, but NOT inline). You have to do this so that you only profile code within that subsystem. These settings make sure a function is generated for the subsystem and no other code is being generated (from blocks outside that subsystem). A subsystem is just a means for users to encapsulate certain parts of models; until you set it as an atomic unit, Simulink treats it like it is just dumped into the top model (all the blocks inside). Only after this setting is done, the encapsulation takes place.
Another topic I'd like to address is FreeMASTER - you can go to the FreeMASTER configuration block and open the advanced settings. Here you'll see 3 modes available:
- Poll-driven - here no interrupt is needed/generated - this is generally not the way you'd like to configure, as the FreeMASTER can get starved and not complete the data transfer to the PC
- Long interrupt - all the message processing is done inside the interrupt
- Short interrupt - the data is saved and queued inside the interrupt - this is generally the mode you'd like to select, as you should always get data out and into the PC application
If you configure the FreeMASTER like in the image below, you'd get stable connection (no '??' data). The only downside to using short interrupt is that data is not instantly transmitted to the application (but the delays are negligible).
Hope this helps! Please let us know if you have further issues/questions.
Kind regards,
Razvan.
