what are the correct high/low maximums for _delay_ms()/_delay_us()

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

what are the correct high/low maximums for _delay_ms()/_delay_us()

Britton Kerin
I guess the high-res maximums are 262.14 ms / F_CPU in MH for
_delay_ms() and 768 us / F_CPU in MHz for _dalay_us() regardless of
the availability of __builtin_avr_delay_cycles(), but
the way the _delay_ms() and _delay_us() descriptions are written this
is not entirely clear.  Am I correct?

If so, I'd suggest rewriting the descriptions for those functions to
not re-use the term "maximal possible delay".  Instead they could say
something like "maximum possible high-resolution delay"
and "maximum possible low-resolution delay".

Britton

Reply | Threaded
Open this post in threaded view
|

Re: what are the correct high/low maximums for _delay_ms()/_delay_us()

Joerg Wunsch
As Britton Kerin wrote:

> I guess the high-res maximums are 262.14 ms / F_CPU in MH for
> _delay_ms() and 768 us / F_CPU in MHz for _dalay_us() regardless of
> the availability of __builtin_avr_delay_cycles(), but
> the way the _delay_ms() and _delay_us() descriptions are written this
> is not entirely clear.  Am I correct?

I think you are.  They work beyond that now (has not always been the
case) but lose a bit of accuracy/resolution.

However, for the usual LED "I want 1 Hz" flasher, it's OK to have two
_delay_ms(500) calls between turning the LED on and off.

--
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)

Reply | Threaded
Open this post in threaded view
|

Re: what are the correct high/low maximums for _delay_ms()/_delay_us()

Britton Kerin
On Thu, Jan 23, 2020 at 1:25 PM Joerg Wunsch <[hidden email]> wrote:

>
> As Britton Kerin wrote:
>
> > I guess the high-res maximums are 262.14 ms / F_CPU in MH for
> > _delay_ms() and 768 us / F_CPU in MHz for _dalay_us() regardless of
> > the availability of __builtin_avr_delay_cycles(), but
> > the way the _delay_ms() and _delay_us() descriptions are written this
> > is not entirely clear.  Am I correct?
>
> I think you are.  They work beyond that now (has not always been the
> case) but lose a bit of accuracy/resolution.
>
> However, for the usual LED "I want 1 Hz" flasher, it's OK to have two
> _delay_ms(500) calls between turning the LED on and off.

Ok thanks.  I still think it's worth carefully documenting where the high/low
resolution threshold is for all cases though.  I was just trying to use the
_delay_us() to cross-check some timer1 code and confused myself a bit
not hitting the expected resolution due to crossing over the threshold.  In
my old age I'd probably make them separate functions as they're somewhat
overloaded as they are.

Britton

Reply | Threaded
Open this post in threaded view
|

Re: what are the correct high/low maximums for _delay_ms()/_delay_us()

Markus Hitter
In reply to this post by Joerg Wunsch
Am 23.01.20 um 23:25 schrieb Joerg Wunsch:

> As Britton Kerin wrote:
>
>> I guess the high-res maximums are 262.14 ms / F_CPU in MH for
>> _delay_ms() and 768 us / F_CPU in MHz for _dalay_us() regardless of
>> the availability of __builtin_avr_delay_cycles(), but
>> the way the _delay_ms() and _delay_us() descriptions are written this
>> is not entirely clear.  Am I correct?
>
> I think you are.  They work beyond that now (has not always been the
> case) but lose a bit of accuracy/resolution.

For a calibrated busyloop see

https://github.com/Traumflug/Teacup_Firmware/blob/master/delay-avr.c

Accuracy is described in comments there.


Markus

--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/