Society of Robots - Robot Forum
Software => Software => Topic started by: corrado33 on July 16, 2011, 02:55:29 PM
-
Man I'm starting a lot of threads lately... 8) 8) Keeping you guys busy.
My question is exactly what the title says. How can you estimate how long code will take to execute?
For example... say I have this pseudocode.
while forever
{
start timer;
while timer is not done
{
do_stuff that takes time;
}
reset_timer;
}
So, sure, that'll work. Let's say your timer is running at 1000 Hz. What if it ends in the middle of the do_stuff that takes time actions? Then it'll have to wait the entire time those actions take to complete. What would happen if the do_stuff took longer than .001 seconds? (The amount of time it'd take a timer running at 1000 Hz to throw the overflow flag) What if it took .06 seconds. It'd be repeating twice inside the loop, but it would take .002 seconds more than the normal loop would take.
Is it normally not a problem since things run really fast on the MCU? What if that loop HAD to repeat at exactly 1000 Hz, every time. I could use an interrupt, but, I wouldn't be sure how to implement it.
This is all theoretical, I'm not actually doing something that concerns this, I was just wondering.
-
Man I'm starting a lot of threads lately... 8) 8) Keeping you guys busy.
My question is exactly what the title says. How can you estimate how long code will take to execute?
One thing to look at is the data sheet for the processor you're using. It should have a section giving the assembly instruction set, and how many cycles it takes each instruction to execute. For AVR's a rule of thumb is to figure about one cycle per instruction.
This is overly simplistic though. The processor architecture, whether it pipelines code, and other stuff I don't even know about would come into play if you want to get serious.
For example... say I have this pseudocode.
while forever
{
start timer;
while timer is not done
{
do_stuff that takes time;
}
reset_timer;
}
You probably would want to use an interrupt routine with the timer, depending on what you're doing with it. You might set a flag in the ISR that the main loop can examine, for example. The timer might be able to do everything you want, so you'd need nothing in the main loop at all.
Again, it depends on what you're doing. The question is too vague to be able to answer very well.
Joe
-
When using PICs and developing code in the MPLAB IDE, one would use the Stopwatch feature to time execution of a piece of code.
If writing in Assembler, then one can count the number of instruction cycles and multiply by the CPU's instruction clock period.
-
This is a very open question, but will give my .02$ worth
Timing code options (I use all of these different approaches)
1) Count instructions - If I am using C I either disassemble or find listing of actual assembly. This gets complicated as you may have several different code paths with different times. Also depending on processor, timing of instructions depends on if the instructions are already in the pipeline... I use this approach on Basic Atom Pros, when I am doing in-line assembly language.
2) Use a system timer. I grab the start time at the beginning of the code I wish to time and grab the end time when it finishes and then print out the time... Often will do this multiple times and get averages, Min's, maxs...
3) Use Logic Analyzer (My favorite way): Depending on what you are timing. If you are wanting to check on timing of specific output, just hook it up and time it. If you are wanting to time code, I use some unused IO pins and at the start of the code change the IO state of 1 (could set high or low or toggle) and at the end change the state (low, high or toggle). If the code has different paths or error conditions, I setup toggles of different IO pins in those paths and then start up the analyzer and run the code.
Making code run at an accurate timing
1) If this is the sole thing that your processor is doing, you would probably get the most accurate and consistent results, if all devices were polled and there were no interrupts. This removes all issues about interrupt propagation delays or unexpected delays while processing your time critical code. You then need to organize your code such that you always start your critical code at the right time. Have it spin until the system timer is at the appropriate value... You then organize the rest of the code, such that you call it every pass or every N passes or queued, such that none of the parts get starved... Lots of options here.
2) Depending on the type of code and the like, run your time time critical code on an interrupt, like lets say a timer interrupt. Depending on how this is setup you can often make this code be uninterruptable... But depending on how long your code runs, this could causes issues like missing characters from USARTS... If you run into issues that with this interrupt the start up time is not accurate enough as it depends on how long it takes for the interrupt to be handled (what instruction was being processed, in another interrupt, in critical section with interrupts disabled). In cases like this I have heard of people who setup their next timer interrupt to interrupt before they actually want their code to start, and then in the interrupt handler, spin until the system timer is at the appropriate time...
That is all for now
Kurt
-
How to calculate how long it takes for your algorithm to do something:
http://www.societyofrobots.com/robotforum/index.php?topic=6648.0 (http://www.societyofrobots.com/robotforum/index.php?topic=6648.0)
-
Thanks admin. :)