AVR Freaks

If you need a precise amount of delay,

probably you should use assembly.

If you just need jitter-free operation,

use a formula that does not require an if that depends on your data:

enum { DELAY=37 } ; // in while loop passes
enum { BUF_BITS=7 } ;
enum { BUF_SIZE=1<<BUF_BITS } ;
// twos complement assumed later
uint8_t buf[BUF_SIZE];
uint8_t jin=0, jout=0;
uint8_t delay_left=DELAY;

while(1) {
    buffer[jin++ & -BUF_SIZE]=PINC;
    volatile uint8_t portv=
            shift(buf[jout++ & -BUF_SIZE] & IN_HIGH) | (PORTC & ~OUT_HIGH); }
            // shift to get the right bit position
    uint8_t port3=portv;
    // getting the timing right on the following
    // if/else might be easier in in-line assembly
    // even slight compilation changes could make a differnce otherwise
    if(delay_left) {
        --delay_left;
    } else {
        PORTC=port3;
    }
} // while

I've often posted in "you can't do this in C" threads; [almost?] always on the C side.

But C has no concept of buffer pointer wrapping.  So my guess is that even with alignment and my other axioms above the C clocks would be double or more.

Only a couple changes to make the above a complete program for Atmel assembler:

    .DSEG
    .ORG 0x400
BUFFER:
    .BYTE 100

    .CSEG
    .ORG 0
; SETUP
    LDI ZH, HIGH(BUFFER)        ; OUTPUT POINTER
    LDI ZL, 0
    
    LDI XH, HIGH(BUFFER)        ;  POINTER
;   LDS XL, offset              ; CALCULATED ELSEWHERE
    LDI XL, 123 ; DELAY IN MICROSECONDS*2

LOOP:
    IN  R16, PINB   ; 1 CYCLE
    STS X, R16      ; 2
    INC XL          ; 1
    LDS R16, Z      ; 2
    INC ZL          ; 1
    OUT PORTD, R16  ; 1
    RJMP LOOP       ; 2     

And yes, I forgot to make the output pin high in my "complete program". ;)

That's why I like my smartphone.  Or other digital camera...

But does it "catch up"?  As I said, as far as I can see, the edges will always be +/- one sample period for >>any<< sampling-type setup.  Right?

So your 'scope has no one-shot or similar mode to show a few cycles across the screen?

With BUF_SIZE=0x100 you would not need the & -BUF_SIZE .

Reliable cycle-accurate timing pretty much requires assembly.

Subcycle-accurate timing is not available.

As another noted, there is a variable delay between the time a signal

changes on a pin and it is available for reading within the AVR.

How big a jitter are we discussing?

Edit: Is there a chance that you have been trying to read or write buffer[0x100]?

Simpler, clearly jitter-free:

enum { DELAY=137 } ; // in while loop passes
enum { BUF_BITS=8 } ;
enum { BUF_SIZE=1<<BUF_BITS } ;
// twos complement assumed later
uint8_t buf[BUF_SIZE];
uint8_t port1=PORTC;
memset(buf, port1, DELAY);  // DELAY passes of sameness

uint8_t jin=DELAY, jout=0;
while(1) {
    buffer[jin++ & -BUF_SIZE]=shift(PINC & IN_HIGH) | (port1 & ~OUT_HIGH);
            // shift to get the right bit position
    PORTC=buffer[jout++ & -BUF_SIZE];
} // while

It's very likely I've missed something.  If I have time later today I will try to test it.

Oh, and the way to compute the number of bytes you'll need for a given delay is simple.  May as well add that to the code.

Note that floating point arithmetic in preprocessor directives isn't supported by GCC for assembler sources, thus the delay is specified in nanoseconds instead of microseconds.

And I suppose there's no reason to limit the buffer to 64 bytes.  Might as well just go for the maximum size.

Also, note that the delay you specify does not include the 0.5-1.5 cpu cycles synchronisation delay imposed by hardware, nor the half-bit (i.e. 1 cpu cycle) phase delay between TX and RX.  The result is likely to be a -0.5 to +0.5 cycle jitter.  A scope or LA would be required to characterise the actual delay offset on real hardware.

Further, it should be possible to change the length of the delay line at runtime by communicating a new value over SPI (or TWI, or another USART, if your AVR has one).  With interrupt-driven SPI slave code, an ISR could compute a new value for DELAY_BYTES and set new values for the head and tail registers [X and Y], and then resynchronise MSPI.  Here's the new code with changes made.  I've omitted the code required to receive runtime changes to the length of the delay line, that is left as an exercise for the reader ;-)

#define F_CPU 20000000

#define __SFR_OFFSET 0
#include <avr/io.h>

#define DELAY_NS 20000

; Must be a power-of-two no greater than half of the available SRAM
#define BUF_SZ_BYTES (((RAMEND + 1) - RAMSTART) / 2)

; 2 <= DELAY_BYTES < BUF_SZ_BYTES
; Since two bytes go  out from the tail of the delay line  before any are added
; to the head, the delay line must be at least 2 bytes long, or 16 samples, for
; a minimum delay of 1.6 us.
#define BITS_PER_US (F_CPU / 2000000)
#define DELAY_BYTES ((DELAY_NS * BITS_PER_US) / 8000)
#if (DELAY_BYTES >= BUF_SZ_BYTES)
  #warning DELAY_US is too long
  #undef DELAY_BYTES
  #define DELAY_BYTES (BUF_SZ_BYTES - 1)
#endif
#if (DELAY_BYTES < 2)
  #warning DELAY_US is too short
  #undef DELAY_BYTES
  #define DELAY_BYTES 2
#endif

; Create a symbol reflecting the real delay.  Examine it with avr_objdump -t
; or similar.
.equ real_delay, (DELAY_BYTES * 8000) / BITS_PER_US

; Index registers by name
#define XL r26
#define XH r27
#define YL r28
#define YH r29

; 10 MHz sample rate  will generate 10 samples per us.  50  us will require 500
; 1-bit samples.  512 samples would fit in  64 bytes.  Although the m168 has 1K
; of SRAM, it is mapped starting at 0x100.  In order to keep the buffer aligned
; to a  power-of-two equal  to its size,  it cannot be  larger than  512 bytes.
; That would permit a 4096 sample delay line.  At 10 MHz, that's 409.6 us.
.section  .bss
.balign   BUF_SZ_BYTES
.comm    dl, BUF_SZ_BYTES

.section .text

.global __do_clear_bss

.global main

main:

; configure SPI for F_OSC/2 = 10 MHz
        eor     r1,     r1
        sts     UBRR0H, r1
        sts     UBRR0L, r1
        sbi     DDRD,   4
        ldi     r16,    (1<<UMSEL01)|(1<<UMSEL00)
        sts     UCSR0C, r16
        ldi     r16,    (1<<RXEN0)|(1<<TXEN0)
        sts     UCSR0B, r16
        sts     UBRR0H, r1
        sts     UBRR0L, r1

; Since  it's implemented  as a  circular  buffer of  bytes, the  delay can  be
; configured with a granularity of 8 bits, or 0.8 us.

; X is  used to point to  the head of  the delay line, where  incomming samples
; will be deposited
        ldi     XH,     hi8(dl+DELAY_BYTES)
        ldi     XL,     lo8(dl+DELAY_BYTES)
; Y is used to point to the tail of the delay line, where outgoing samples will
; be withdrawn
        ldi     YH,     hi8(dl)
        ldi     YL,     lo8(dl)

; Fill the MSPI TX buffer and wait for  the first RX byte to be ready, i.e. the
; first read must  occur at least 16  cycles after the first  write.  The third
; write must  occur no more  than 32  cycles after the  first write, or  the TX
; buffer will be empty, and there will be a gap.
        ld      r16,    Y+                        ;
        sts     UDR0,   r16                       ;         1st write
        ld      r16,    Y+                        ;                   2
        sts     UDR0,   r16                       ;         2nd write 2

; 3 cycles per pass, total 15 cycle wait.
        ldi     r16,    5                         ;
wait:
        dec     r16                               ;
        brne    wait                              ;                  15

; Run the delay line.  Loop must be exactly 16 cycles
loop:
        lds     r16,    UDR0                      ; 2       1st read  2 = 21
        st      X+,     r16                       ; 2                 2
        ld      r16,    Y+                        ; 2                 2
        sts     UDR0,   r16                       ; 2       3rd write 2 = 27
        andi    XL,     (BUF_SZ_BYTES-1) & 0xFF   ; 1
        andi    XH,     (BUF_SZ_BYTES-1) >> 8     ; 1
        andi    YL,     (BUF_SZ_BYTES-1) & 0xFF   ; 1
        andi    YH,     (BUF_SZ_BYTES-1) >> 8     ; 1
        rjmp    .+0                               ; 2
        rjmp    loop                              ; 2
                                                  ; = 16

Input on RXD, output on TXD. For the m168 and friends, thats PD0 and PD1.

I'd intended OP to replace it with the appropriate << or >> .

Perhaps I should have added the comment shift(IN_HIGH)==OUT_HIGH.

Try the attached .hex file.  Built with avr-gcc.  I still haven't tested it myself, but I will try this afternoon.

Rookie mistake :(

When I was applying the mask to X and Y in the main loop, I was clearing the higher bit representing the base address of the buffer.  The result is that both X and Y were pointing at the GP register file.  I was clobbering state.  The machine was running amok!

New code below.  Tested, and 'works', although I haven't confirmed if the delay is correct.  But the input is in fact now duplicated on the output.

#ifndef F_CPU
  #define F_CPU 20000000
#endif

#define __SFR_OFFSET 0
#include <avr/io.h>

; Set to desired delay
#define DELAY_NS 20000

; Must be a power-of-two no greater than half of the available SRAM
#define BUF_SZ_BYTES (((RAMEND + 1) - RAMSTART) / 2)

; 2 <= DELAY_BYTES < BUF_SZ_BYTES
; Since two bytes go  out from the tail of the delay line  before any are added
; to the head, the delay line must be at least 2 bytes long, or 16 samples, for
; a minimum delay of 1.6 us.
#define BITS_PER_US (F_CPU / 2000000)
#define DELAY_BYTES ((DELAY_NS * BITS_PER_US) / 8000)
#if (DELAY_BYTES >= BUF_SZ_BYTES)
  #warning DELAY_US is too long
  #undef DELAY_BYTES
  #define DELAY_BYTES (BUF_SZ_BYTES - 1)
#endif
#if (DELAY_BYTES < 2)
  #warning DELAY_US is too short
  #undef DELAY_BYTES
  #define DELAY_BYTES 2
#endif

; Create a symbol reflecting the real delay.  Examine it with avr_objdump -t
; or similar.
.equ real_delay_ns, (DELAY_BYTES * 8000) / BITS_PER_US

; Index registers by name
#define XL r26
#define XH r27
#define YL r28
#define YH r29

; 10 MHz sample rate  will generate 10 samples per us.  50  us will require 500
; 1-bit samples.  512 samples would fit in  64 bytes.  Although the m168 has 1K
; of SRAM, it is mapped starting at 0x100.  In order to keep the buffer aligned
; to a  power-of-two equal  to its size,  it cannot be  larger than  512 bytes.
; That would permit a 4096 sample delay line.  At 10 MHz, that's 409.6 us.
.section  .bss
.balign   BUF_SZ_BYTES
.comm    dl, BUF_SZ_BYTES

; Determine  address  linker  will  select  for  buffer  (used  for  condtional
; compilation below).   Can't think  of a  way to extract  this from  the .comm
; declaration of dl above.   I expect it can't be done.   Rather, would need to
; specify a custom section and use --section-start= when building.  Meh.
#if BUF_SIZE_BYTES > RAMSTART
  #define DL BUF_SIZE_BYTES
#else
  #define DL RAMSTART
#endif

.section .text

.global __vector_default
        rjmp    reset
.global __vector_default

reset:

.global __do_clear_bss

.global main

main:

; configure SPI for F_OSC/2 = 10 MHz
        eor     r1,     r1
        sts     UBRR0H, r1
        sts     UBRR0L, r1
        sbi     DDRD,   4
        ldi     r16,    (1<<UMSEL01)|(1<<UMSEL00)
        sts     UCSR0C, r16
        ldi     r16,    (1<<RXEN0)|(1<<TXEN0)
        sts     UCSR0B, r16
        sts     UBRR0H, r1
        sts     UBRR0L, r1

; Since  it's implemented  as a  circular  buffer of  bytes, the  delay can  be
; configured with a granularity of 8 bits, or 0.8 us.

; X is  used to point to  the head of  the delay line, where  incomming samples
; will be deposited
        ldi     XH,     hi8(dl+DELAY_BYTES)
        ldi     XL,     lo8(dl+DELAY_BYTES)
; Y is used to point to the tail of the delay line, where outgoing samples will
; be withdrawn
        ldi     YH,     hi8(dl)
        ldi     YL,     lo8(dl)

; Fill the MSPI TX buffer and wait for  the first RX byte to be ready, i.e. the
; first read must  occur at least 16  cycles after the first  write.  The third
; write must  occur no more  than 32  cycles after the  first write, or  the TX
; buffer will be empty, and there will be a gap.
        ld      r16,    Y+                        ;
        sts     UDR0,   r16                       ;         1st write
        ld      r16,    Y+                        ;                   2
        sts     UDR0,   r16                       ;         2nd write 2

; 3 cycles per pass, total 15 cycle wait.
        ldi     r16,    5                         ;
wait:
        dec     r16                               ;
        brne    wait                              ;                  15

; Run the delay line.  Loop must be exactly 16 cycles
loop:
        lds     r16,    UDR0                      ; 2       1st read  2 = 21
        st      X+,     r16                       ; 2                 2
        ld      r16,    Y+                        ; 2                 2
        sts     UDR0,   r16                       ; 2       3rd write 2 = 27
        andi    XL,     lo8(BUF_SZ_BYTES-1)       ; 1
        andi    XH,     hi8(BUF_SZ_BYTES-1)       ; 1
        andi    YL,     lo8(BUF_SZ_BYTES-1)       ; 1
        andi    YH,     hi8(BUF_SZ_BYTES-1)       ; 1
#if DL < 0x100
        ori     XL,     lo8(dl)                   ; 1
        ori     YL,     lo8(dl)                   ; 1
#else
        ori     XH,     hi8(dl)                   ; 1
        ori     YH,     hi8(dl)                   ; 1
#endif
        rjmp    loop                              ; 2
                                                  ; = 16

; Catch-all
__vector_default:
        reti

New .hex file for m168 attached.  Built for 20 MHz, and a 20 us delay.  Also, built without using -nostartfiles, so the full CRT is linked.  This clears the buffer to zero since it is in .bss.  It's not necessary, but ensures no spurious output at the beginning with the random contents of SRAM after a power-up.  I've built and tested it both with and without the CRT and it works either way.

EDIT:  Whoops, had the wrong hex file attached.  It was built for a 1 ms delay.  Replaced with new file built for 20 us.

I'd also have to dig into it, but I think that port DMA would work well.  Probably [as I remember my reading] with sacrificing entire ports as in my polling example on AVR8.

theusch wrote:

"The AVR's UART doesn't work right" gets old after a while.

You're not kidding.  I feel as though my patience and tolerance has gone down rapidly over the last year ;-)  ... I'm always impressed when the likes of you or Cliff keep at it patiently.  I'm trying.  At least, that's what my wife says.

El Tangas wrote:

Luckily there were 2 clocks to spare now there is

If there were no slack cycles, it could still have to be made like that, but like this is quite beautiful, at the limit of the MCU

Well actually, I was being lazy, since I had 16 cycles to play with.   This is a little uglier, but it saves two cycles for future use, and still handles most any device.

; Fill the MSPI TX buffer and wait for  the first RX byte to be ready, i.e. the
; first read must  occur at least 16  cycles after the first  write.  The third
; write must  occur no more  than 32  cycles after the  first write, or  the TX
; buffer will be empty, and there will be a gap.
        ld      r16,    Y+                        ;
        sts     UDR0,   r16                       ;         1st write
        ld      r16,    Y+                        ;                   2
        sts     UDR0,   r16                       ;         2nd write 2

; 3 cycles per pass, total 15 cycle wait.
        ldi     r16,    5                         ;
wait:
        dec     r16                               ;
        brne    wait                              ;                  15

; Run the delay line.  Loop must be exactly 16 cycles
loop:
        lds     r16,    UDR0                      ; 2       1st read  2 = 21
        st      X+,     r16                       ; 2                 2
        ld      r16,    Y+                        ; 2                 2
        sts     UDR0,   r16                       ; 2       3rd write 2 = 27
#if BUF_SZ_BYTES <= 0x100
        andi    XL,     lo8(BUF_SZ_BYTES-1)       ; 1
        andi    YL,     lo8(BUF_SZ_BYTES-1)       ; 1
#else
        andi    XH,     hi8(BUF_SZ_BYTES-1)       ;     1
        andi    YH,     hi8(BUF_SZ_BYTES-1)       ;     1
#endif
#if DL < 0x100
        ori     XL,     lo8(dl)                   ; 1
        ori     YL,     lo8(dl)                   ; 1
#else
        ori     XH,     hi8(dl)                   ;     1
        ori     YH,     hi8(dl)                   ;     1
#endif
        rjmp    .+0                               ; 2
        rjmp    loop                              ; 2
                                                  ; = 16

I hope it doesn't offend your sense of limitless beauty ;-)

I've tidied up a few silly things, but I'm not going to post yet another copy of this thing unless someone asks ;-)

Yes, but then the maximim delay would be 256*8*0.1 = 204.8 us. Good enough for the OP, but by using 1 kB on, say, a 328P, that goes up to 819.2 us ;-)
If I ever think of something useful to do with those 4 cycles, I can always change it. I suppose we could toggle a pin, or increment a whole port, so that the MSB would signal at F_CPU/4096. Is that useful? ;-)

Well, please don't get bored with it on my account :)

On the contrary, this was an interesting nut to crack :)

an LED that says "I am processing input" (as opposed to just waiting for input). You know how people love a flashing LED. But only if its blue.

Hmmm.  We can just about do it:

; once for init
        eor     r30,    r30
        mov     r31,    r30
        sbi     DDRD,   7

; in the loop
        adiw    r30,    1                         ; 2
        sbrc    r31,    7                         ; 1/2
        out     PIND,   r31                       ; 1

The second part takes 4 cycles total, regardless.  If this takes our four extra cycles in the loop, the effect is that Z is incremented every 16 cpu cycles.  Z will overflow every 65,536*16 = 1,048,576 cycles.  Bit 7 of r31 will be low for 524,288 cycles, and then high for 524,288 cycles.  When it is low, the out is skipped, and PORTD remains unchanged.  When it is high, the out is executed, and PD7 is toggled.  The first toggle will turn PD7 high, the next will turn it low, etc.  It will be toggled at F_CPU/16, for a frequency of F_CPU/32 = 625 kHz.  Since bit 7 of r31 will be high an even number of times, the last toggle before Z overflows and (bit 7 of r31 is again 0) will leave PD7 low.

The overall effect is that an LED across PD7 and GND will appear to flash at a frequency of F_CPU / (16 * 65536 * 2) = 9.54 Hz.  That's pretty fast, but it's slow enough to perceive.  The off half of the flash will indeed be off, while the 'on' half will actually have the LED pulsing a square wave at 625 kHz.

Is that useful? ;-)

Note that PD3-7 (and PD2 if you don't enable XCK) will also toggle, but since they aren't outputs, only the pull-ups will be enabled/disabled.

As has been noted, there is always XCK (PD4), which outputs a 10 MHz square wave while the loop is running.  As @El Tangas has mentioned, it isn't necessary for MSPI to function in the manner we are using it here, so it need not be made an output.

Or a way to attach an analog pot to adjust delay...

That wouldn't need any cycles from the loop.  It can be done, similar to using SPI/TWI/whatever to set a new delay can be done as I suggested in #29.  So set a new delay with a POT, you'd also need a switch or button to 'latch' a the new value.  The switch would trigger an interrupt to read the POT, compute new offsets for X and Y, then restart the delay line.  For that matter, the button could just be on /RESET, with the POT position read only once on startup.  To set a new delay, change the POT, and just reset the AVR.

You could constantly poll the POT for a new value, but that would continually break the timing of the main loop.

If this basic solution works for you, I might take a crack at adding the variable delay.  I've got some unanticipated projects coming up, so it may not happen fast.

Or a couple pins to divide down FAST input (like 5Megs+)... and mul it back up again after processing

Are you proposing a kind of digial heterodyne?

I'm not really taking the p...

Go on.  Of course you are ;-)

The trouble there is that there are >>two<< pointers.  One for the head of the circular buffer, and one for the tail.  They won't wrap at the same time, so it's not easy to predetermine where to unroll the loop.  It would be harder still if the delay were variable.

However, just by moving to a 256 byte buffer, we can avoid auto-increment altogether, as Lee has done with his software-only solution, and we save a few cycles permanently:

; Run the delay line.  Loop must be exactly 16 cycles
loop:
        lds     r16,    UDR0                      ; 2
        st      X,      r16                       ; 2
        ld      r16,    Y                         ; 2
        sts     UDR0,   r16                       ; 2
        inc     XL                                ; 1
        inc     YL                                ; 1
        ; 4 cycles available
        rjmp    loop                              ; 2

This is a loop we >>can<< unroll indefinitely and with impunity, giving us 6 free cycles instead of 8.  Mind you, there is the minor wrinkle that the inc instructions will affect the S, V, N, and Z flags, but careful coding could manage that restriction.  For example, since the C flag is unaffected by inc, it could be used for inquiry whenever possible.

If we unrolled to the end of flash, an m168 would have up to 2K words of flash available in 6-cycle chunks to do other work, with the remaining 6K words consumed by the unrolled loop. (!!)

Now, since Y is preloaded with the address of the start of the circular buffer (while X is loaded with an offset representing the delay), we could use incremental constant offsets in the indexing for each pass through the unrolled loop:

; Run the delay line.  Loop must be exactly 16 cycles
loop:
        lds     r16,    UDR0                      ; 2
        st      X,      r16                       ; 2
        ld      r16,    Y                         ; 2
        sts     UDR0,   r16                       ; 2
        ; 7 cycles available

        inc     XL                                ; 1
        lds     r16,    UDR0                      ; 2
        st      X,      r16                       ; 2
        ld      r16,    Y+1                       ; 2
        sts     UDR0,   r16                       ; 2
        ; 7 cycles available
.
.
.
        inc     XL                                ; 1
        lds     r16,    UDR0                      ; 2
        st      X,      r16                       ; 2
        ld      r16,    Y+62                      ; 2
        sts     UDR0,   r16                       ; 2
        ; 7 cycles available

        inc     XL                                ; 1
        lds     r16,    UDR0                      ; 2
        st      X,      r16                       ; 2
        ld      r16,    Y+63                      ; 2
        sts     UDR0,   r16                       ; 2
        ; 4 cycles available

        inc     XL                                ; 1
        subi    YL,     -64
        rjmp    loop                              ; 2

This buys another cycle per pass, and we can unroll by 64.  In this way, we'd have 63*7+4 = 445 cycles to play with (We can unroll by more, in chunks of 64, offering 445*chunks-2 cycles to play with).  However, it doesn't prevent the condition flags from being modified, since X is still incremented every pass.  Again, since X is offset from Y and not 'synchronised' with the unrolled loop, we can't use the same technique.  Some of those would be involved in preserving flags across the unrolled passed to avoid the impact of the inc.

Then again, if we constrained the granularity with which the delay could be set, we could take advantage of the same offset technique for the head pointer.  Since X doesn't support index operations with an offset, we'd have to switch to using Z for the head, but no matter.  Then we'd have 8 cycles to play with for every pass, with no need to preserve flags across passes.  For example:

; Run the delay line.  Loop must be exactly 16 cycles
loop:
        lds     r16,    UDR0                      ; 2
        st      Z,      r16                       ; 2
        ld      r16,    Y                         ; 2
        sts     UDR0,   r16                       ; 2
        ; 8 cycles available

        lds     r16,    UDR0                      ; 2
        st      Z+1,    r16                       ; 2
        ld      r16,    Y+1                       ; 2
        sts     UDR0,   r16                       ; 2
        ; 8 cycles available
.
.
.
        lds     r16,    UDR0                      ; 2
        st      Z+62    r16                       ; 2
        ld      r16,    Y+62                      ; 2
        sts     UDR0,   r16                       ; 2
        inc     ZL                                ; 1
        ; 8 cycles available

        lds     r16,    UDR0                      ; 2
        st      Z+63    r16                       ; 2
        ld      r16,    Y+63                      ; 2
        sts     UDR0,   r16                       ; 2
        ; 4 cycles available

        subi    ZL,     -64                       ; 1
        subi    YL,     -64
        rjmp    loop                              ; 2

This would give us 63*8+4 = 508 cycles, and no need to preserve flags.  However, it would mean that the delay could only be set to multiples of 64 bytes, or 512 bits.  At 10 MHz sampling, that's a granularity of 51.2 us.  Not especially useful to the OP.

We could reduce the granularity from 64 bytes to 32 bytes, or 25.6 us, leaving us 31*8+4 = 252 cycles to play with, and no need to preserve flags.  So it's a trade-off between available cycles and granularity of delay.  As is, the fully rolled-up loop has the best possible granularity at 0.8 us, which is still greater than the 0.5 us the OP had specified.

Personally I don't see an advantage to trading granularity for cpu cycles.  I would stick with by-64 unrolled loop and the restriction on preserving flags across passes within the unrolled loop.  445 cycles should be enough to, as you suggested, handle the POT directly in the loop, even with the restriction on flags.  I'd still want an input to 'latch' a new delay value from the POT, since even the 445 cycles might not be enough to do proper filtering on the ADC input, so the >>length<< of the delay line would fluctuate with any noise on the ADC input.

Note that for all of these unrolling options, there is a bit of wiggle room w.r.t. the cycles used between passes.  That is, while there are nominally 7 cycles between passes in the first example, since the MSPI is buffered, we could use, say, 11 in one gap, and 3 in the next gap.  So long as we don't allow the buffers to empty or overflow, all will be well.  Careful cycle counting will be required, and the whole unrolled loop must be cycle-accurate overall.

Naturally, I leave any actual coding as an exercise to the interested reader ;-)

Well, @El Tangas, I kind of hate you now ... This is going to tend to draw my attention away from a multitude of projects and responsibilities ;-)

I count 6 words in the base loop (LDS, STS, LD, ST).  And you need words to use the other 8 cycles, right?  So more like 10...  [probably missed something...]

[don't let sparrow2 see this]  Well, it can be.  But one needs to be pretty familiar with the code generation model of the particular C toolchain.

And as I think I mentioned earlier

I've often posted in "you can't do this in C" threads; [almost?] always on the C side.

 

But C has no concept of buffer pointer wrapping.

It is indeed hard to get to min machine cycles in C where a better algorithm/code sequence with a particular micro's instruction set uses concepts not part of the C language.  The mentioned wrapping; the concept of Carry; unsupported operand widths; and others.

You've put a sow's ear to the task of making a silk purse.  So to get best results the proposed solutions reserve two of three AVR pointer registers exclusively to the task.  GCC is pretty good about that in "memcpy" type loops so we might have gotten that far.  But the wrapping to mod 256 or whatever isn't part of C.  Thus the ASM-only (or implemented as inline fragments) solutions above will give you better performance in this case than C only. 

Now, I don't think anyone has explored the SPI version in C, which is a bit more forgiving (with "extra" cycles) than the straight polling approaches.

[If one starts with a buffer of exactly 256 bytes on a mod 256 boundary, then the pointer wrapping could be:

-- if starting address is 0x100, then wrap by assigning 0x01 to the _H register.  LDI one cycle one word.

--  same as above for "odd" pages 0x300 0x500 ...

-- if starting address is 0x200 or other "even" pages, then wrap by clearing the low bit of _H register.  CBR one cycle one word

Hmmm--odd or even one could use method 1 I guess.]

[[ Wouldn't that come out the same as ST X, rrr INC _L and use  ST X+,rrr LDI XH, HIGH(buffer) ?  ]]

[edit]  As reloading _H takes same words/cycles as INC _L, the latter is probably better because buffer on mod 256 isn't necessarily needed (although the width needs to be 256).  That would be at the expense of a little more one-time work at setup to take care of wrap of the input pointer offset from output pointer.

/*
connect pin XCK to SCK
use MISO MOSI for input, TXD for output

connect SS to another port pin
*/

uint8_t buffer[0x100];
uint8_t jin, jout;

// set up left as an exercise for the reader

while(1) {
    if(UCSR0A USART0A & _BV(UDRE0)) {
        UDR0=buffer[jout++];
        //  UCSR0A USART0A=_BV(UDRE0);  useless, possibly counterproductive
    }
    if(SPSR & _BV(SPIF) {
        buffer[jin++]=SPDR;
        // SPIF cleared automatically
    }
}

Also, documentation seems to imply that UDREn is not cleared by an ISR.

If 22 cycles is not fast enough, I suppose four lines of in-line assembly

(two each for load and store) would do the trick for an aligned 256-byte buffer.

Note that though both SPIs have to run at the same frequency,

they do not have to have the same phase.

By activating SS at the right time, the delay can be selected to within a bit time.

Note that since SS is an input, one will need another wire to control it.

I think the granularity is 2 CPU cycles.

That said, 100ns is only 0.005 of 20 microseconds.

Note that 256*8 bits is enough for a 200 microsecond delay.

According to documentation, /SS is an input in slave mode.

It needs a wire to something.

An internal pull-up would be counter-productive.

On further thought, I suspect that playing with the SPI mode can get down to singe-cycle resolution.

For subcycle resolution, one might need to adjust Fcpu.
 

I'd forgotten about the SPI speed limit.

The next MSPI speed available is Fcpu/4 .

A SPI slave can be set to read a bit on either the rising or falling edge of SCK.

At a bit rate of F_cpu/2, those edges are one cycle apart.