Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26203

Re: Short blocking delay in Cortex-M0+

Show all headers | View raw

On 24/03/17 12:23, pozz wrote:
> Il 23/02/2017 17:15, pozz ha scritto:
>> During startup, I need a short and not precise delay, before configuring
>> clocks, timers and other peripherals (at startup the CPU runs with
>> internal clock).
>>
>> What do you suggest?
>>
>> I think there's a simpler method than configuring a hardware timer.
>>
>> I need to check the status of an input pin, *after* enabling internal
>> pull-up. I'd like to introduce a short delay after enabling internal
>> pull-up, otherwise there's a risk I will read a transient level (maybe 0
>> or 1).
> 
> I found some interesting code in Atmel Software Framework. It is based
> on the following function defined in delay.c file:
> 
> __attribute__((optimize("-Os")))
> __attribute__ ((section(".ramfunc")))
> void portable_delay_cycles(unsigned long n)
> {
>     (void)n;
> 
>     __asm (
>         "loop: DMB    \n"
>         "SUB r0, r0, #1 \n"
>         "CMP r0, #0  \n"
>         "BNE loop         "
>     );
> }
> 

Someone should teach the Atmel folk about gcc inline assembly...

They might also realise that "written in AVR32 assembly" and "portable"
don't really go together!

> 
> In delay.h there are some macros:
> 
> void portable_delay_cycles(unsigned long n);
> 
> #define cpu_ms_2_cy(ms, f_cpu)  \
>         (((uint64_t)(ms) * (f_cpu) + (uint64_t)(7e3-1ul)) / (uint64_t)7e3)
> #define cpu_us_2_cy(us, f_cpu)  \
>         (((uint64_t)(us) * (f_cpu) + (uint64_t)(7e6-1ul)) / (uint64_t)7e6)
> 
> #define delay_cycles               portable_delay_cycles
> 
> #define cpu_delay_s(delay) delay_cycles(cpu_ms_2_cy(1000 * delay, F_CPU))
> #define cpu_delay_ms(delay) delay_cycles(cpu_ms_2_cy(delay, F_CPU))
> #define cpu_delay_us(delay) delay_cycles(cpu_us_2_cy(delay, F_CPU))
> 
> 
> However I didn't measure how precise are the delays generated by those
> functions.

For a multi-MHz cpu clock, they should certainly be better than µs
precision.  The point of the function is to put the code in ram, so that
its timing is not dependent on things like flash access delays.

Of course, if interrupts are enabled, it's a different matter.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Short blocking delay in Cortex-M0+ pozz <pozzugno@gmail.com> - 2017-02-23 17:15 +0100
  Re: Short blocking delay in Cortex-M0+ John Speth <johnspeth@yahoo.com> - 2017-02-23 09:00 -0800
    Re: Short blocking delay in Cortex-M0+ Tim Wescott <tim@seemywebsite.com> - 2017-02-23 13:15 -0600
    Re: Short blocking delay in Cortex-M0+ pozz <pozzugno@gmail.com> - 2017-02-24 09:51 +0100
      Re: Short blocking delay in Cortex-M0+ rickman <gnuarm@gmail.com> - 2017-02-24 04:26 -0500
      Re: Short blocking delay in Cortex-M0+ Tim Wescott <seemywebsite@myfooter.really> - 2017-02-24 14:22 -0600
    Re: Short blocking delay in Cortex-M0+ Jack <jack4747@gmail.com> - 2017-02-24 02:22 -0800
    Re: Short blocking delay in Cortex-M0+ Don Y <blockedofcourse@foo.invalid> - 2017-02-24 10:51 -0700
    Re: Short blocking delay in Cortex-M0+ Stefan Reuther <stefan.news@arcor.de> - 2017-02-24 18:29 +0100
      Re: Short blocking delay in Cortex-M0+ Dave Nadler <drn@nadler.com> - 2017-02-24 13:03 -0800
    Re: Short blocking delay in Cortex-M0+ mrfirmware <mrfirmware@gmail.com> - 2017-03-22 09:29 -0700
      Re: Short blocking delay in Cortex-M0+ mrfirmware <mrfirmware@gmail.com> - 2017-03-22 09:48 -0700
        Re: Short blocking delay in Cortex-M0+ Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-03-22 22:02 +0100
        Re: Short blocking delay in Cortex-M0+ David Brown <david.brown@hesbynett.no> - 2017-03-23 10:05 +0100
          Re: Short blocking delay in Cortex-M0+ Tim Wescott <seemywebsite@myfooter.really> - 2017-03-23 12:54 -0500
            Re: Short blocking delay in Cortex-M0+ mrfirmware <mrfirmware@gmail.com> - 2017-03-23 12:52 -0700
  Re: Short blocking delay in Cortex-M0+ Don Y <blockedofcourse@foo.invalid> - 2017-02-23 13:54 -0700
  Re: Short blocking delay in Cortex-M0+ Paul <paul@pcserviceselectronics.co.uk> - 2017-02-24 10:36 +0000
  Re: Short blocking delay in Cortex-M0+ pozz <pozzugno@gmail.com> - 2017-03-24 12:23 +0100
    Re: Short blocking delay in Cortex-M0+ David Brown <david.brown@hesbynett.no> - 2017-03-24 12:57 +0100
      Re: Short blocking delay in Cortex-M0+ pozz <pozzugno@gmail.com> - 2017-03-24 13:54 +0100
        Re: Short blocking delay in Cortex-M0+ David Brown <david.brown@hesbynett.no> - 2017-03-24 15:21 +0100
          Re: Short blocking delay in Cortex-M0+ Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-03-24 21:26 +0200
            Re: Short blocking delay in Cortex-M0+ David Brown <david.brown@hesbynett.no> - 2017-03-25 01:11 +0100

csiph-web