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

Groups > comp.arch.embedded > #25865

Re: Short blocking delay in Cortex-M0+

Show all headers | View raw

On 2/23/2017 10:00 AM, John Speth wrote:
> 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++);
> }

The optimizer can still "rewrite" your code in ways that won't
guarantee the delay for YOUR_DELAY=2*N won't be twice the delay
for YOUR_DELAY=N (within the cost of initialization differences).
(think: loop unrolling)

You're stuck having to pick a value, compile and then measure to
VERIFY the actual delay exceeds your requirement.  Then tweek your
value and try again.

You can try to isolate compiler influences by implementing the
routine in ASM (either inline or as a separate ASM function
bound in by the linkage editor).  But, this still leaves you
vulnerable to changes in the processor (family) and application
(i.e., cutting and pasting into other projects or elsewhere in
this project).

[Brief (Solution Systems) was a classic example of how timing
loops could make a piece of software useless in short order.
A command line bogo-parameter was used to drive the timing
loop for the key repeat function.  As processors got faster
and started relying on bigger/integrated caches, it became
impossible to tweek that bogo-value to a point where you could
get your finger off the keyboard fast enough to prevent
multiple keystrokes being synthesized from your *one* keypress]

And, regardless, a different compiler (e.g., a new release of
your EXISTING compiler) can alter the actual delay associated
with a particular value of YOUR_DELAY.

As the OP hasn't put any parameters on the size of his actual
desired delay, a error of 10% -- or 90% -- may be insignificant...
or, disasterous (in terms of the UX).

Use something that has known, predictable TIMING.  Would you use
an *approximation* of an addition operator to SUM two values?

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