Re: [avr-libc-dev] Re: [bug #17216] change to the ../util/delay.h header for increased functionality

[Bill Perry]

On 03/06/2011 02:49 PM, Weddington, Eric wrote:
> > -----Original Message-----
> > From: address@hidden
> > [mailto:address@hidden On
> > Behalf Of Joerg Wunsch
> > Sent: Sunday, March 06, 2011 12:14 PM
> > To: Bill Perry; address@hidden
> > Subject: [avr-libc-dev] Re: [bug #17216] change to the ../util/delay.h
> > header for increased functionality
> >
> > As Bill Perry wrote:
> >
> > > The only thing left (for me) is the possibility of adding a
> > > _delay_ns() function.
> > Are you willing to submit that as a patch against the current SVN
> > version?
> >
> > If so, please don't forget the documentation (which is just the
> > doxygen comment on top of it).  The documentation should clearly point
> > out the limits in the applicability of this function, so it's
> > immediately obvious that nobody could expect a 12.5 ns delay on a CPU
> > clocked with 1 MHz. ;-)
> I question the whole viability of a _delay_ns() function. If someone wants a 
> resolution that small, then they should be able to do the calculation and use 
> the __builtin_avr_delay_cycles() builtin function instead. It should be no more 
> than a few cycles anyway at the clock rates that we're talking about.

I am again astonished at the resistance to adding this function.

Why not provide the convenience function
rather than make users have to create it for themselves?
What does it hurt?


*=============== Slight Rant ....*

The same argument about being able to calculate the cycles could also go for
_delay_ms() and _delay_us()

As I brought up over and over again on AVRfreaks, it isn't about 
resolution at all, it is about being
able to easily create short delays of less than 1us being used for 
hardware setup timing.

For delays this short, there is no alternative to CPU spin loops.
There were two problems with the original delay loop code and why it 
could be used for these type of delays.
1) It didn't guarantee you got a delay at least as long as you wanted.
2) The rounding at the very low/short end (which is where these delays 
are) created the biggest error/issues.

These 2 issues were quite ironic in that the only time where there was 
absolutely no alternative
to using a CPU delay loop, is where the <util/delay.h> routines broke 
down the most and failed to deliver.
(all this has been fixed now with the newer code that uses the built in 
cycle delay function)

_delay_ns() is simply about making it even easier to specify these very 
short hardware setup
delays which are often specified in ns in the data sheets.

So for example, I have a ks0108 glcd library (in wide use on Arduino).
ks0108 modules have several different setup delays that are less than 1us
The best way to ensure that the library code "just works" for everyone 
is to ensure that it uses a delay function that auto scales
based on processor speed.

Some of the more critical hardware setup delays for a ks0108 chip are 
320ns, 140ns, 200ns.

Yes it is often impossible to provide these delays but the code needs to 
have way to specify delays
that are are short as possible without undershooting to ensure that the 
code never violates the hardware setup timing

Having a _delay_ns() function makes it really easy for developers as 
they can then call a delay function
that lets them specify their delays in nano seconds which come
directly off the data sheet and those nano second delay values can be 
used directly
vs having to write a wrapper function or convert the ns to us (which 
while fairly simple is subject to human error)

And don't forget having to deal with cycle rounding.
The library code can and does have options to specify how the cycle 
rounding should be done
and _delay_ns() would be no exception.


*=============== Rant over....*_
_

I believe that computers should work to make life easier for humans
and to me, having _delay_ns() function makes it easier to create sub 
microsecond
delays when those delays are usually spelled out in ns in the data sheets.


--- bill