AVR Freaks

You simply MUST count all instruction cycles used by EVERYTHING used in creating & calling the delay.  Are you doing that?

If you want it extremely exact, you also have to say what you count as part of the delay?  Are you including the call & the return?  What happens when an IRQ happens during the delay?

Account for your fixed & repetitive timings separately when calculating.  Doubling the repetitive & ignoring the fixed does not give double time!

but fixed delays will work fine here.

Each half period of the external clock applied must be longer than one system clock cycle to ensure correct sampling. The external clock must be guaranteed to have less than half the system clock frequency (f ExtClk < f clk_I/O /2) given a 50/50% duty cycle. Since the edge detector uses sampling, the maximum frequency of an external clock it can detect is half the sampling frequency (Nyquist sampling theorem). However, due to variation of the system clock frequency and duty cycle caused by Oscillator source (crystal, resonator, and capacitors) tolerances, it is recommended that maximum frequency of an external clock source is less than f clk_I/O /2.5.

Ever think that you should be using a different chip such as a Cortex M0+ for this project instead?

More timers, faster clock, etc... means no having to fudge with a software delay or the Fclk/2.5 limitation at all!

can you see the code and make correction where i im doing wrong?

No, did you bother to count up how many cycles the code will take?  

Request 1 integer less than you do now (if requesting 157, request 156 instead)...add in enough nops to fill in the fractional remainder to give you the exact time.  Then  all of your requests will be correct. 

http://www.avrbeginners.net/

In that case, the busy wait will end a little late.

Timers keep running during interrupt-handling:

Interrupts have to be strategically timed to mess up a timer-based busy wait.

Usually a timer-based busy wait need not interfere with other timer-using tasks.

All you need is a timer that ticks at CPU speed and to which no task assigns.

also often spelled "nibble"

https://en.wikipedia.org/wiki/Nibble

Here's how I did cycle-accurate delays in one project:

tmp  = 16	; Scratch register

.macro delay_c cycles								;
  ; Fail on negative.								;
  .if \cycles < 0								;
	.error "delay_c called with a negative cycle count"			;
  ; Fail on too many cycles.							;
  .elseif \cycles > (((3 * 256) + 7) + 2)					;
	.error "delay_c called with too many cycles"				;
  ; Use subroutine for long delays.						;
  .elseif \cycles >= 10								;
	; Value of 256 passed as 0.						;
	ldi	tmp, ((\cycles - 7) / 3) % 256					; 1
	rcall	delay_loop							; 3+
    ; Extra one or two cycles not possible with subroutine's 3-cycle loop.	;
    .if ((\cycles - 10) % 3) == 2						;
	rjmp	.+0								; 2
    .elseif ((\cycles - 10) % 3) == 1						;
	nop									; 1
    .endif									;
  ; Too short for subroutine, inline loop instead.				;
  .elseif \cycles >= 9								;
	ldi	tmp, \cycles / 3						; 1
0:	dec	tmp								; 1
	brne	0b								; 1/2
    ; Extra 1 or two cycles not possible with 3-cycle loop.			;
    .if (\cycles % 3) == 2							;
	rjmp	.+0								; 1
    .elseif (\cycles % 3) == 1							;
	nop									; 1
    .endif									;
  ; Short delays can be done in the same or fewer words, without clobbers.	;
  .else										;
    .if \cycles >= 8								;
	rjmp	.+0								; 2
    .endif									;
    .if \cycles >= 6								;
	rjmp	.+0								; 2
    .endif									;
    .if \cycles >= 4								;
	rjmp	.+0								; 2
    .endif									;
    .if \cycles >= 2								;
	rjmp	.+0								; 2
    .endif									;
    ; Odd cycle not possible with rjmp.						;
    .if (\cycles % 2) == 1							;
	nop									; 1
    .endif									;
  .endif									;
.endm										;

delay_loop:									;
	dec	tmp								; 1
	brne	delay_loop							; 1/2
	ret									; 4

Use like this:

	delay_c	46

I used it in an app running at 8.25 MHz, so the above resulted in a 5.818 µs delay.

Most it can do is 777 cycles, which at 16 MHz is 48.5625 µs.

EDIT:  sp

The datasheet spcifies what bits of Z are used: just enough to cover the entire range.

I've lost track here.  Your solution, joey, is a build-time solution, right?  Didn't OP want run-time?

I thought that the "newer" GCC facilities were cycle-accurate?

If there is a reasonable range of values, couldn't a Duff's device-type-thing be used?

theusch wrote:

Didn't OP want run-time?

Isn't that what "using parameter as delay needed" (in the title) means ?

fair point - and it's the way the 'C' delay works, too.

C'mon; you are stretching things now, aren't you?  Are you arguing that there is, then, no difference between e.g. delay routines that are expanded at build time such as your example code, and those that pass a parameter at run-time?

Perhaps I'm getting too old, or the virus is affecting me.

is, to me, at build time.  It cannot accept a parameter at run time...let's say 8-bit (for convenience) ADCH, can it?

Why am I having such a hard time grasping how

is relevent to the thread?  Are you saying that you code can take, e.g. the value in ADCH at run time after a conversion and produce a proportional delay?  I thought that is what OP was asking for in #1.  Which post can be extracted to produce this varying ADCH-proportional delay?

Boy, I must have tickled your isolation bone.  OK, tell me the exact wording to distinguish between build-time and runtime?  Call them case A and case B.  I read that OP wanted case B.  Did you read that differently?

The answers to this might be important, as it may well be the niggle.

And that was a bad example to make it clear as an example of a runtime/dynamic/not-the-same-value-every-time ?

I'm very confused again -- no, you cant pass that and have your macro lines such as

.elseif \cycles > (((3 * 256) + 7) + 2)	

  work.  How?  "cycles" is ADCH at build time when the macro is expanded.  How do you know is ADCH is less than 0 or greater than a million?  Won't ou be working with the I/O address at this time?

Who asked for run-time delay, and you gave build-time.  And no, substituting ADCH value as "cycles" ain't gonna carry out your statements.