Go Down

Topic: NOP's for DUE TIming (Read 978 times) previous topic - next topic

scottez50

I've read a myriad of postings regarding the use of NOP's for precision timing, so far nothing has nailed the issues I'm having.  I need - at least - the precision of one cycle (11.9nS for the 84MHz Arduino Due I'm using) to provide the correct timing for reading a high speed ADC.  The use of NOP's  for this sort-of works, but there's inconsistency; it seems to depend on what instructions are before and/or after on whether I get a single cycle delay.  There's some merit to the use of the right compiler optimizations, , but I've tried:
#pragma GCC optimize ("-O1")
#pragma GCC optimize ("-O2")
#pragma GCC optimize ("-O3")
or none
I see shorter delays for sure when I use the -03 setting, but still get inconsistency. 

Here's what I've done so far;
For NOP's I've settled on the form:
__asm__ __volatile__ ("nop\n\t")
although I'm not convinced that this form is any different than:
asm("nop\n);
From what I've read there may, or more likely not, be some benefit in using the volatile qualifier, but I've not seen any difference. 
Also I've not discovered what the \n and \t switched do, would love to find a reference for this.
To use more than one NOP in a row, I'm using this form, for example for three;
__asm__ __volatile__ ("nop\n\t nop\n\ nop\n\")
And to make things easier, I made a number of defines such as:
#define NOP3  __asm__ __volatile__ ("nop\n\t nop\n\ nop\n\")

All of this is still not totally working, I'm still getting unexpected results in my timing.  I add one, two, three NOP's and it behaves as I'd expect, then I add one more and then get a much larger delay or none.  And depending where I place the NOP results in different delays.

If anyone has some insight into this I'd be eternally grateful. 

westfw

You won't get 1cycle accuracy on a Due running from flash, because the flash memory takes more than one cycle to read ("wait states")
You might try a run-from-ram function...

scottez50

Shannon,

I've tried placing the statement "__attribute__ ((section (".ramfunc")))" in front of my function that uses NOP's for timing and is having these issues with inconsistency, and initially it seems to be much better!  I've got several places now that have different timing so need to go back re-time these sections, but it looks very promising. 

Thanks for your good suggestion! 

Go Up