Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
CPU throughput used by a sketch
31-08-2013, 07:15 PM,
#1
CPU throughput used by a sketch
If we were using an RTOS, there would be a mechanism to measure idle time for the CPU, but we are just using libraries. I notice that the IDE prints % of flash memory used by a sketch, but I haven't discovered any way of displaying idle time per second (or, alternatively, % of max CPU throughput used). Perhaps I haven't performed an adequate search. Does anyone have any suggestions? This measurement is useful for determining if a higher, or lower, power CPU would be desirable, or a higher or lower clock speed.
- David.
Reply
31-08-2013, 09:12 PM,
#2
RE: CPU throughput used by a sketch
There is no such thing and in my opinion the only way to get CPU usage is to calculate it from your program. You'd have to use interrupts to have a reliable timing source and to increment some counters.


(31-08-2013, 07:15 PM)ashton Wrote: If we were using an RTOS, there would be a mechanism to measure idle time for the CPU, but we are just using libraries. I notice that the IDE prints % of flash memory used by a sketch, but I haven't discovered any way of displaying idle time per second (or, alternatively, % of max CPU throughput used). Perhaps I haven't performed an adequate search. Does anyone have any suggestions? This measurement is useful for determining if a higher, or lower, power CPU would be desirable, or a higher or lower clock speed.
- David.
It is easier to complain than it is to do, but it is better to do than it is to complain.
Reply
01-09-2013, 02:37 AM,
#3
RE: CPU throughput used by a sketch
If there is no purely S/W way to do it, I will tell you how it has been done before... maybe this will help somebody:
1. Upon entering every module, including interrupt handlers, put a certain output pin high, then put it low just before exiting the module.
2. Observe the pin under worst case loading conditions.
3. Measure the time that the output pin is high for a variety of 1 second intervals using an oscilloscope.
4. Calculate the ratio of the worst case high time divided by 1 sec and this is throughput usage.

This method should provide a more precise measurement of CPU usage than by calculating it, I'll bet, but it underestimates CPU usage somewhat by ignoring the time taken by the CPU to switch contexts.

- David.
Reply
01-09-2013, 04:09 PM, (This post was last modified: 01-09-2013, 04:11 PM by pingotg.)
#4
RE: CPU throughput used by a sketch
I think nearly everyone is using no OS on their Pinguino so there are no context switches.

Then it just comes down to whether the CPU (and/or I/O) is fast enough (or program written to be fast enough).

However, for hard real time the above tends to be inadequate. But is anyone doing such who doesn't already know that LOL

For almost (*) everything, the CPUs are plenty fast enough.

(*) almost - is where the headaches can start Sad

John
Reply
03-09-2013, 07:28 PM,
#5
RE: CPU throughput used by a sketch
The context switches to which I was referring were interrupts, rather than due to multitasking. So the error due to neglecting fetching/storing context registers would be proportional to the interrupt rate... probably a minor error unless the interrupt rate = high and the processing code = short.

However, if I have time, I might try making all processing, except initialization, interrupt driven and have code incrementing an idle counter run in a non-interrupt process, then output a serial character upon overflow of the counter. Since I know the rate at which the counter increments and how long it takes to overflow, I should be able to calculate an average idle rate.


Thanks for your help.
- David.
Reply
03-09-2013, 09:11 PM, (This post was last modified: 03-09-2013, 09:12 PM by pingotg.)
#6
RE: CPU throughput used by a sketch
I think for most people they just pick a CPU that's so fast compared to what they need to get done that it isn't worth measuring those kinds of things.

With the low prices now, that makes a lot of sense.

In my early days with the PIC32 I did a few timings, found it ran about half the speed I'd guessed (*), and as it was still at least 10x faster than I typically needed, shrugged and carried on!

(*) more wait states than I expected, by far

I simply haven't needed an RTOS. I avoid interrupts when I can (i.e. mostly) as that way you know exactly what's happening. Easier debug, too.

John
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)