Clock cycles for certain functions

Projects Programming
1

I need to know how many clock cycles certain functions require:

analogRead() <- is reading data into an array
delayMicroseconds() <- does the function itself consume any clock cycles?
Serial.println()

My problem is that I should see a 1kHz square wave, and instead I'm seeing 22.7Hz. I think it's due to the other commands I'm running between modulations.

2

You can find this in two ways:-

  1. Look at the source code for each function, assemble them separately, look at the object code and count the cycles each instruction takes.
  2. Time them using one of the timers.

However generating a signal based on just code execution time is not going to work because you have interrupts going off all over the place and that screws the timing calculations.

3

I'm hoping to get away from actually timing them myself. I was hoping that there would be documentation on these functions and their processor times. I know the Amtel's datasheet has details on the ADC's clock cycle usage but I don't know how that translates to analogRead(). Nor do I know about the other functions.

The problem is that these functions are slowing my program down, and perhaps if I knew by how much, I could come up with an elegant timing solution.

4

Sorry as far as I know no one has documented this, it must be a minority sport. If timing is that critical you would be better off using assembler. Most things take the time they take because they do necessary stuff.

5

delayMicroseconds() tries hard to be close to accurate, analogRead() takes about 110us I think.

You are using delay() or delayMicroseconds() to generate a waveform - that won't be accurate, use millis() and micros() instead - that way you won't need to account for execution time overheads of your housekeeping code.

6

I'll try my project with millis() and micros() and see if that helps. However, my problem comes from multiple analogRead() functions per duty cycle. If it takes 110us to do one read, then 100 reads is taking more than a tenth of a second! That seems unreasonable, though any delay is going to screw up my program.

7

Don't use analogread than, there is an example w/o:
http://oscilloscopeexpress.blogspot.com/

8

If it takes 110us to do one read, then 100 reads is taking more than a tenth of a second

Check your maths!
I make it 11mS

9

Yeah, you're right, my math was off, but that's still an unacceptable delay. I've moved on to other methods, though, and this one's on the back burner for the time being.

10

If you're worried about the (mostly) dead-time of an "analogRead", it is an easy function to pick apart into "input-select, start-conversion", "wait-ready" and "read-result".

11

You can also pick up analogue read results in the ADC Conversion Complete interrupt handler.

There are a good many ways to skin this sort of cat. What are you trying to accomplish?