Guesstimating cpu usage as you prototype

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm looking for some ideas on how you guys do this. That is, as you prototype, build hardware, crank code, how do you figure if your cpu or clock has enough cycles to do all the tasks ?

I know, I know, you're supposed to build a complete and detailed spec beforehand, sometimes down to the cycle ... Hmmm. But projects grow, you change features, you come up with new ideas to implement something in a better way, etc, etc.

Most embedded apps are interrupt driven. The mainline code is usually fairly (or relatively) simple, and the bulk of the work is done in interrupts. Not that you spend much time in interrupts - the idea is be in and out as quick as you can.

So how are you determining if you're allocating time correctly ? There are a couple of methods I use, all pretty simple.

Toggle a pin on entry and exit of an interrupt. It helps to have spare pins available in prototyping so you can dedicate one for each interrupt you want to instrument. I'll develop on a larger AVR just for that reason sometimes, knowing that I will port down to a target AVR.

This give you a nice easily read hardware vizualization of the code occupancy. You can quickly see where time is being spent inordinately, and can see when things happen "out of order". It's also a fairly simple and obvious method, documented all over the place, but it deserves mentioning since it works ...

Another method is to put out a voltage that is indicative of cpu business. Use an 8-bit variable to hold the business value. This gets incremented on each entry to an interrupt or entry to a mainline processing function, and decremented on each pass through the idle loop section of the mainline. Limit it to 0-254.

Each pass through the idle section then spits that value out on a (hopefully spare) port as an 8-bit binary value. The port can also be updated each time the value is updated for even more "accuracy". This port can be passed into an R2R ladder or a DAC to give a direct voltage indication of cpu activity. Note - I haven't tried this yet, but it sounds sound.

One could also stuff that value into a PWM register to alter the duty cycle of a hardware PWM signal. Then just watch the duty cycle of the pin on a scope, or put it into an averaging circuit. I have done this - works pretty well.

So how do you guys attack this ?

Dean 94TT
"Life is just one damn thing after another" Elbert Hubbard (1856 - 1915)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use the chaos method. It's more or less, suck on a finger, test the wind and set sail. ;-)
I guess it all comes down to experience. As long as you're designing with a know CPU family, you normally have a pretty good idea of what can be done. Also, you can often try implementing some simulated (or real) functionality on a deb-board to see how hard they load the CPU.
If it's a new and unknown CPU, it's a VERY different story. What may seem to be a piece of cake, can be a nightmare when it turns out that because you're using this pin for THIS, that pin can no longer be used for THAT, or because the (Philips (did I say that out loud ?)) datasheet is lacking information, or worse, incorrect.

I use the same approach as you with flipping extra pins, and monitor them with a scope. Never tried the accumulating register variant, but it sounds like a nice idea to use it with a PWM channel.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

...it sounds like a nice idea to use it with a PWM channel...

I never thought of that one. Often the complete app has all/nearly all the pins used up so us poor software geeks have to make do with what is available. A 16-bit PWM would work great for...

...My "normal" method for gauging throughput & response time is to count the number of loops through my mainline per second (or other suitable time base). Being a neo-Luddite and ignoring such niceties as a [resource-sucking] RTOS, almost all my apps have a main loop that looks for flags set by the ISRs or does things based on time (triggered by a heartbeat timer, so still ISR-driven although indirectly).

I also have the luxury that (almost) all of my apps have a serial interface and/or display of some sort. So I can force the display of my status info if needed.

If you've got the pin(s), toggling a pin in the heartbeat ISR and/or when the WDR is done is a great sanity check that your app is still alive. I keep that going as long as practical during dev and even during production--what difference does it make if the "power OK" LED is solid on or blinks at 1Hz? (as a compromise, it can be turned off for (say) 10ms every half second or full second, and it can't even be seen by the eye but can be seen on the 'scope.

I've also timed my ISRs where significant processing needs to be done in the ISR, like with a high-speed counter with 32-bit "trip" points.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.