I am trying to determine if I can run some interrupt driven code, and still have enough processor cycles to keep other code running fast enough.
I already know how often the interrupt will be generated, and about how often the remainder of the program should be ran. But, how does one determine how many processor cycles, and therefore how much time, a particular loop of code will take?
Another way is to store the time (Micros) in at the start/end of each loop or code block and then output that data on the serial port at some convenient point (i.e. in a non-critical code section).
Pretty much anything you do will impact your code timings, it's a case of finding something that minimizes it.
The way I measured the time for a piece of code was as follows...
I put the code in a function which would be called by the program that normally used it.
I then wrote another sketch that recorded millis() and then called the same function 1000 times and recorded millis() again at the end of it. Get the difference between the two times and divide by 1000.
You could use more repetitions if you wish.
By the way I checked the assembler code that the compiler produced for the function to make sure it was the same in both cases.
I then wrote another sketch that recorded millis() and then called the same function 1000 times and recorded millis() again at the end of it. Get the difference between the two times and divide by 1000
Be aware that significant discrepancies can show up using this method if the compiler is able to inline your function in your timing version of the code vs. your actual code (or vice versa).
I then wrote another sketch that recorded millis() and then called the same function 1000 times and recorded millis() again at the end of it. Get the difference between the two times and divide by 1000
Be aware that significant discrepancies can show up using this method if the compiler is able to inline your function in your timing version of the code vs. your actual code (or vice versa).
That's why I checked the assembler code. I had to define the function like this
You could analyze the assembly code and determine the cpu cycles. You will have to take into account any loops and conditional statements. Steps:
Compile your sketch in the IDE with the verify button.
Go to your temp folder and enter the build[SOME NUMBER].tmp directory
Run "avr-objdump -S [SKETCH NAME].elf". This will output assembly mixed with the c++ source. It's probalby easiest to save it to a file by adding "> out.as" if you are on a unix. I don't know how to do this on windows. If you don't have avr-objdump installed system wide I believe you can find it in arduino/tools/avr/bin/avr-objdump
Open the out.as in a text editor or look through the output from avr-objdump in the terminal
Locate your function
Go through the function from top to bottom. Look up each instruction in the AVR instruction set manual http://www.atmel.com/images/doc0856.pdf. In the bottom of each description you will see how many cpu cycles the instruction requires.
You will have to take into account all jumps and conditional branches. If your function has if statements or loops with varying iterations, then the execution time will of course vary.
Add up the cycles you have counted.
This will be easy for simple functions, but rather painful for complex ones. Instead you could count the cpu cycles of your function on the arduino by using the 16 bit timer 2 with the prescaler set to 1. Reset the counter in the start of or before your function and read the counter in the end of or after your function. Then you have the number of cycles.
Thank you all for the great replies. I will probably stick with the simplest millis() based method, only because the more I have to learn about the system, the less likely the project is to get finished!