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

Groups > comp.arch.embedded > #25866

Re: Short blocking delay in Cortex-M0+

Show all headers | View raw

Am 23.02.2017 um 18:00 schrieb John Speth:
> First thing after main() starts, configure your pin and run a spin loop
> based delay, then read the pin.  There's probably no need for a timer at
> that stage of start up.
> 
> void delay(void)
> {
>   // Use volatile so the optimizer will not nullify this code
>   volatile int i;
>   for(i = 0; i < YOUR_DELAY; i++);
> }

If you want a piece of assembly to show up in your binary, write that
piece of assembly (and not some piece of C code that happens to produce
that piece of assembly today). Even with volatile, the compiler is free
to decide between a register or a variable, possibly different increment
and compare instructions, unrolling the loop, etc.

And if you're too lazy to implement parameter passing in assembler to
get a variable delay, it's definitely not hard to write a function that
burns 10000 cycles. Wrap that in a C loop, and if your compiler
generates anything between 1 or 100 cycles for the C code, you'll still
have 1% accuracy.


  Stefan

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