greets,
if I have the following for loop:
for (int n = 0; n <= 10000; n++){ __asm__("nop\n\t");}
Will this loop execute exactly in 10000 clock cycles? Or does n++ take a cycle to increment? What about the comparison n <= 10000?
thanks
Will this loop execute exactly in 10000 clock cycles?
It involves sixteen bit values on an eight bit processor, so no.
Each pass thru the for loop takes ~12uS if I recall correctly.
You might as well do
delayMicroseconds(625);
as that is how long 10000 nop's would take:
1/16,000,000 * 10,000 = 0.000625 = 625uS
CrossRoads:
Each pass thru the for loop takes ~12uS if I recall correctly.
You mean even if the for loop is empty?
You might as well do
delayMicroseconds(625);
as that is how long 10000 nop's would take:
1/16,000,000 * 10,000 = 0.000625 = 625uS
10000 was an arbitrary number as an example.
I usually use the util/delay.h functions _delay_ms and _delay_us. I think _delay_us uses asm("nop\n\t")'s according to the F_CPU define. And I guess _delay_ms uses 1000 _delay_us's.
I was wondering if e.g. there is a need for a lot of nop's, the only way is to have them all written sequentially, i.e asm("nop\n\t""nop\n\t""nop\n\t".....)? Or is there a shorter method to tell the compiler the number of nop's?
10000 was an arbitrary number as an example.
And mine was an arbitrary answer.
Tell us what you want to do, not how you think you want to do it.
When I want fast SPI transfers, I write them out:
SPDR = array[x]; nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;nop;
(spdr? need to look)
with SPI clock set for 8 MHz to make the code wait out the SPI clocks and not mess with the SPI library interrupt. I have even turned off interrupts prior to a transfer when I needed multiple bytes of data to be blasted out in one big burst with no breaks in the timing.
naut:
Or does n++ take a cycle to increment? What about the comparison n <= 10000?
Of course they will (take cycles). The processor doesn't loop and test in zero cycles.
You could always find out for yourself by disassembling your example:
a6: 80 e0 ldi r24, 0x00 ; 0 (1)
a8: 90 e0 ldi r25, 0x00 ; 0 (1)
aa: 00 00 nop (1)
ac: 01 96 adiw r24, 0x01 ; 1 (2)
ae: 27 e2 ldi r18, 0x27 ; 39 (1)
b0: 81 31 cpi r24, 0x11 ; 17 (1)
b2: 92 07 cpc r25, r18 (1)
b4: d1 f7 brne .-12 ; 0xaa <setup+0x4> (1/2)
Cycle counts in brackets. I count 8 cycles per loop.
If you are using 1.5.8 onwards of the IDE there is a function call that generates precise delays:
__builtin_avr_delay_cycles(n); // n is the number of cycles
Interesting! So no more 3-4uS granularity?
At 8 cycles running at 16 MHz I make that 500 nS.
Will this loop execute exactly in 10000 clock cycles?
10001 iterations can never take 10000 anythings 
Why not measure the time yourself by recording micros() before and after the FOR loop and examining the difference.
Cuts out ALL the speculation
...R
AWOL:
Tell us what you want to do, not how you think you want to do it.
I'm making a BPM calculator and need around 20 to 30uS precision, preferably 10uS. I had some working code, but I was not getting good resolution with the arduino millis() and micros() functions. So I thought I'll use nop's or the timer/counters directly, at lower presclaler setting.
If you are using 1.5.8 onwards of the IDE there is a function call that generates precise delays:
Nope, didn't know there was an update. I'm using AStudio 6 more often, the __builtin_avr_delay_cycles should work.
Of course they will (take cycles). The processor doesn't loop and test in zero cycles.
ye, I should've asked how many, not if...
thanks for the input
I don't see how nops are going to help here. Use the hardware timer.