If you add your on LOG, TRACE or debug hooks, e.g. sending messages via UART to see if MCU is On/Off ... you might get a clue (with timestamps when you receive messages).
Should be possible with dedicated debug and trace hooks added in the code.
I verified with the developers that there is no way to do this on the BCM2073x because the BLE stack runs threads that are invisible to the developer, making it nearly impossible to insert hooks to measure performance.
1 of 1 people found this helpful
You can use the empirical approach, start with one slave advertising and connecting followed by a second one,..., up to eight. I would also try the same scenario with all the slaves advertising at the same time. I that configuration I would add more than 8 slaves advertising (to create extra noise), maybe 10-15.
For the PUART I would generate traffic regularly. If the traffic is based on user action I would generate traffic every 500ms to 1s (even fake traffic).
The application thread that is dedicated to your application processes the event queue (entry point), so you will need to look at that closely, making sure the thread is doing its job on a timely manner.Someone suggested time stamps in your logs, I think it is a good one to add.
I believe you are using the timer (or maybe both) for your internal application design. I would also try to play with the period of the timer, decreasing it (so the timer callback executes more often).
Thanks for the advices.
As for the timestamp, I couldn't find an API to check CPU cycle time.
Only thing available seems like fine timer tick which is 12.5 ms resolution.
So, I don't think it is useful for any CPU profiling.
>> I verified with the developers that there is no way to do this on the BCM2073x
>> because the BLE stack runs threads that are invisible to the developer,
>> making it nearly impossible to insert hooks to measure performance
Just providing hooks just before and after ARM WFI (Wait For Interrupt) in your Idle task
would be sufficient for the SDK users to measure CPU utilization.
Cortex M3 does not have Performance Counters (as a Cortex A9). If ETM is available in silicon - no clue
(but it would need anyway a special debugger).
Maybe, you can use the SYSTICK (if not used by RTOS: if so you might use something from RTOS or the SYSTICK counter itself just by reading).
Or you drive a GPIO pin and measure with scope from outside.