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

Groups > comp.arch.embedded > #25860

Re: Short blocking delay in Cortex-M0+

Show all headers | View raw

Il 23/02/2017 18:00, John Speth ha scritto:
> On 2/23/2017 8:15 AM, pozz wrote:
>> 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).
>
> 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++);
> }

Yes, it's a solution. But I haven't ANY idea what is the value of 
YOUR_DELAY based on the real delay.

Considering I'm talking about a precise processor (Cortex-M0+) and 
knowing the core clock at startup (in my case 8MHz), is it possible to 
calculate YOUR_DELAY value based on the delay in microseconds?

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