avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] A _delay_us_2() with 16 bit max & nop shimming


From: pen_sq
Subject: [avr-libc-dev] A _delay_us_2() with 16 bit max & nop shimming
Date: Sun, 20 Aug 2006 17:40:34 -0400
User-agent: KMail/1.9.3

The major malfunction here - this DOES NOT compile without optimization.  
Would it be acceptable to #define it away in that case? The lesser bug is 
that _delay_us_2() only works with a constant; who wants float arithmetic at 
runtime, anyway?

This delay.h adds _delay_us_2() which is more precise and has a larger max 
than _delay_us().  There is also a  _delay_loop_2b() added.

The _delay_us_2() uses the 4 clock, 16 bit sbiw loop. If a below 
minimum delay is commanded, it will resolve into the right number of NOPs. 
Also, 1,2, or 3 NOPs are appended to shim out the 4 clock loop exactly.

The other function,  _delay_loop_2b(), is a more constant-demanding 
_delay_loop_2(). The change is in using clobber to take R24+R25 for itself, 
and LDI'ng them directly with the constant argument. The way _delay_loop_2() 
works, it is less predictable with the chance of doing a MOV shuffle. 

The else {/*NOTREACHED*/} could be filled in with a still larger delay routine 
for almost unlimited us count.

The included delaytest.c is the only testing I did on this delay.h; the 
included listing is for straight -O. The C code skews a few lines after the 
generated assembler.

Attachment: delay.diff
Description: Text Data

Attachment: delay.h
Description: Text Data

Attachment: delaytest.lst
Description: Text Data

Attachment: delaytest.c
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]