How long is foobar() in processor time?

Projects Programming
1

I am trying to read/detect pulses from an opto-interrupter and wonder which is faster, pulseIn() or using interrupts() on pin2. But each would need to 'do something' to be useful, and that takes additional time.

Where can I find information about the time taken by each of the standard functions etc in the reference section?

My thoughts being that I could add the times for each routine & sub-routine to estimate how many opto-interrupter pulses I could reasonably detect per second without detracting from the performance of the main program.

I understand that the above would not be totally accurate but it may be better than my current suck-it-and-see attempts to speed-up the program.

Geoff

2

I don't think the time for functions to execute is documented.

Plus in the case of pulseIn it will be highly dependent on how long the pulse takes to arrive.

Interrupts have a certain setup/teardown time (around 65 clock cycles from memory of a recent thread). Again from memory, from the time of an interrupt to its being serviced is around 3.5 uS. That isn't too bad. However a tight loop checking for a pin change (like in pulseIn) is likely to react faster. But during a tight loop you can't do anything else. Whilst waiting for an interrupt you can.

... to estimate how many opto-interrupter pulses I could reasonably detect per second without detracting from the performance of the main program.

Using pulseIn will detract from the main program because it just sits there waiting for the pulse. It doesn't leave the function until it arrives (or your specified timeout period elapses).

3

There is nothing to stop you looking at the source code to get an idea of what a function does - remember this is open source.

4

Thanks Nick,
I had been worrying that my interrupt handler might be slowing the overall program but using your numbers as a guide, my motor could spin up to 60,000 RPM before the interrupt-handler used all the processor time. As my motor can only do 6,000 RPM it is obviously only taking 10% of the time (at 16MHz)

It would still be interesting to know the relative speeds/timings of various functions.

Mark, I wish I had enough years left on my calender to take up your suggestion but I don't. It's hard enough learning to apply the functions without trying to figure what they are doing at machine-level.

Geoff

5

True but the code often has comments in it, and they tend to stay in step with the code better than separate documentation pages.