bugAVR C Runtime Library - Bugs: bug #17216, change to the ../util/delay.h...

 
 

bug #17216: change to the ../util/delay.h header for increased functionality

Submitted by:  None
Submitted on:  Thu 27 Jul 2006 11:45:35 AM UTC  
 
Category:  Feature Request Severity:  1 - Wish
Priority:  7 - High Item Group:  Header files
Status:  Fixed Assigned to:  Joerg Wunsch <joerg_wunsch>
Percent Complete:  100% Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  Any
Fixed Release:  1.7.2

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 12 May 2011 06:08:20 PM UTC, comment #7: 

I'm going to close this bug report based on Bill's comments in comment #6.

If someone wishes to add support for a __delay_ns() function then please submit a working patch to the Patch Tracker for avr-libc.

Eric Weddington <arcanum>
Project Administrator
Fri 04 Mar 2011 09:15:22 PM UTC, comment #6: 

Guys,
In my mind bug #30363 solved the all the functional problems
and even enhanced the capabilities by adding some
additional rounding functionality/capabilities.

For me, what remains is whether or not a new function should be added.

1) _delay_ns()
This is a convenience function for those people that are using
the delays for very short hardware type delay setup timing.
For some reason there was some passionate objection to this
function on avrfreaks. Not sure why in that many of the issues
brought up also exist in the other _delay_xx() functions.

NOTE:
There is some other rambling in this bug report (by me)
that was mainly do to state of things at the time
(the inability to accurately control the delay behavior
and get accurate cycle rounding).

At this point, all my rambling comments can be
ignored because of the additional functionality
that is already available in the
latest <util/delay.h> provided by the update in #30363
and now that __builtin_avr_delay_cycles() is available.

It is now possible to easily get very accurate cycle delays
and also get accurate time based delays from <util/delay.h>
with user definable cycle rounding - which is what my requests
for added functionality were really about.

The only thing left (for me) is the possibility of adding a
_delay_ns() function.

--- bill

Bill Perry <bperrybap>
Fri 04 Mar 2011 06:21:47 PM UTC, comment #5: 

Joerg, this is in your court, can you take a look at this one?

Eric Weddington <arcanum>
Project Administrator
Thu 17 Sep 2009 07:39:44 PM UTC, comment #4: 

Further continue discussion from the avrfreaks thread:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=619023#619023

I think it is easy to set proper expectations for a new _delay_ns() function through proper documentation so that people won't get a false impression that the routines provide better precision than is actually possible

My overall desire is to have more accurate and more predictable delays for the short delays and more importantly that a delay is never shorter than what was requested.

The drop in alternate routines that Hans-Juergen do both of these in a fully backward compatible way.

Long term it may be good to even re-write Han's routines to use the  __builtin_avr_delay_cycles() function or even provide an additional builtin delay function that take 2 arguments:
- a CPU clock rate
- a time to delay.
That way the entire functionality is handled by the compiler.

Bill Perry <bperrybap>
Mon 17 Aug 2009 09:40:41 PM UTC, comment #3: 

Is is possible to move this forward?

The existing delay macros/functions do have problems.

For example, when using _delay_us(), if the delays are short,  the code is too simple and will insert too many cycles by using a loop count of 1 on a 3 cycle delay loop instead of a variable number of NOPs. This means you can never get a delay shorter than 3 cycles.
Also, when calculating the number of loops for the 3 cycle delay function, truncation instead of rounding up occurs, which means that the delay can be shorter than requested. The remaining 1 or 2 cycles needed are simply lost.
This function does not properly handle the delay when the number of cycles needed is not a multiple of 3.

_delay_ms() is also too simple. When the delay is long, it drops into a loop calling a routine that is using a fixed number of clocks. Since the delay inside each interation of the loop is not exact, the divergence between the desired delay and the actual delay expands with each iteration through the loop. Unfortunately the fixed number of clocks chosen is a short delay, which means there will be many iterations of this loop.
The same rounding error as described above in _delay_us() also exists in this routine other than the multiple is 4 rather than 3.

The new versions of the delay functions, treat the delay cycles in their entirety so they don't suffer from those types of problems and are able to achieve delays accurate to within 1 clock cycle.

   

IMHO creating the needed documentation for the new delay.h should not be a roadblock as it is fairly simple and straightforward.

As far as the sbiw instruction goes, this is already being used by the existing implementation.
The existing implementation calls _delay_loop2() which uses sbiw

What is needed to get the ball moving again?

Bill Perry <bperrybap>
Mon 11 Aug 2008 02:59:31 AM UTC, comment #2: 

The last comment by Joerg is over a year old. Either we need to fix the new functionality, or close this bug report.

Eric Weddington <arcanum>
Project Administrator
Sun 13 May 2007 09:46:38 PM UTC, comment #1: 

Sorry, processing delayed for the following reasons:

. doxygen documentation is missing
. the SBIW instruction used in _delay_loop_3() is marked as
  not being available in all devices; a proper implementation
  has to reflect this

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Thu 27 Jul 2006 11:45:35 AM UTC, original submission:  

Seems that Hans-Juergenover at AVRfreaks.net has expanded the delay routines to be more functional

as per Jörg Wunsch I am filing this report with the hope that it makes it to the next version of AVRlib

T

See

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=30242

for complete post

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bperrybap (Posted a comment)
  • -email is unavailable- added by arcanum (Updated the item)
  • -email is unavailable- added by joerg_wunsch (Updated the item)
  •  

     

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-05-12 arcanum StatusNeed Info => Fixed
        Percent Complete0% => 100%
        Open/ClosedOpen => Closed
        Fixed ReleaseNone => 1.7.2
    2008-10-17 arcanum StatusNone => Need Info
    2008-08-11 arcanum ReleaseNone => Any
    2008-03-17 arcanum CategoryHeader => Feature Request
        Severity3 - Normal => 1 - Wish
    2007-05-13 joerg_wunsch Assigned toNone => joerg_wunsch
    2007-05-06 arcanum Priority9 - Immediate => 7 - High
    2007-01-08 joerg_wunsch Item GroupNone => Header files
    2006-08-24 arcanum Priority5 - Normal => 9 - Immediate

    Back to the top


    Powered by Savane 3.5