Delay function in ARM programming

Question

I have just started programming on ARM, I had some experience on AVR but not that much. The question is probably too trivial but the material about ARM is too little on the net... sorry anyways.

I know for implementing delays in ARM we can use timers or busy-loops. I tried those methods out. But one of my friends suggests there is a "delay.h" headerfile for arm that contains all the necessary delay functions just like avr, delay_ms and ... .

First of all, as stupid as this question may sound, is there really a built-in delay function in ARM programming. Is it in delay.h?

If so, why is the use of timers for implementing delays so popular? Why don't they just use the built-in function?

I'm studying LPC17xx series.

Answer 1

Many compilers and libraries support the ARM family. I wouldnt waste time searching for a single solution defined in a single filename. That is most certainly not "the" solution for "ARM".

As with AVR and most other processors, certainly microcontrollers, you have the choice of blocking in a foreground loop either using a calibrated loop, or polling a timer. You can also use a timer based interrupt if need be. It depends on what you are needing to perform a delay for and what else might be going on during that delay. Depending on the specific chip and amount of time you want to delay you might be able to put the chip asleep for that period of time.

If you are using a library for other things like SPI, I2C, etc for the target processor and toolchain then you likely have timer routines as well and can just use those. If you are rolling your own (most portable but also the most work) then look at the timers, in the long run it will be easier to maintain code that is based on a timer rather than based on a calibrated (count to N) loop.

There are a number of toolchains and libraries tailored to the NXP LPC family in particular if that is the path you wish to take.

In no way, shape, or form. Is there a single solution that you should limit yourself to. Not for ARM not for AVR, not for any of them.

Answer 2

Sometimes code will be run in a context where nothing else is going on. If the processor sets an I/O bit, then runs a bunch of instructions that take a total of 1ms to execute, and then clears the I/O bit, then the wire controlled by that bit will pulse high for 1ms. Simple delay methods can be useful in such contexts. They are far less useful, however, in contexts where other things may be going on. If while the aforementioned delay was running, an interrupt occurred that required 100us to service, the pin would be pulsed high for 1.1ms rather than 1ms. Worse, if one tries to use such a delay within an interrupt service routine, the main-line code and all lower-priority interrupts will be suspended until such delay is complete.

Generally, the aforementioned approach to implementing is appropriate when either (1) one is writing something like a boot-loader that should be able to operate without interrupts, and nothing else will be going on while it's running; (2) one needs a delay which is sufficiently short there's not much point trying to find something else to do. For example, if one is using a 32MHz processor to communicate with a device that requires 1.6us of idle time between data bytes, inserting code that spends 52 cycles doing nothing would mean the ARM could be well-positioned to send the next byte about 1.6us later. By contrast, if the ARM tries to find something else to do, it would likely be busy doing that at the end of the 1.6us, and wouldn't send the next byte until some time later.

Answer 3

Think of an ARM CPU as a full-blown CPU that you might use for an operating system such as Linux. Now imagine what would happen if you blocked execution on the entire chip whenever you wanted time delay functionality. The whole thing would lock up during the delay, leading to a completely unusable experience for any kind of user-interactive system. That's why timers are preferred.

Timers are useful because they avoid the blocking situation. The CPU continues executing code, and jumps back to a handler routine once the timer elapses. This offers a form of asynchronous operation that allows for much more flexible code.

In architectures that don't directly support internal timers, but do support external interrupts, an external timing device can be used. The timer is programmed with a time offset (usually a scalar and multiplier) and an interrupt number. When the external timer triggers the interrupt, the CPU reads an interrupt table to find the interrupt vector, which is a linear address to which execution is transferred in order to handle the timer event.

Answer 4

It is of course possible to use an ARM processor to do a simple delay. See my code below. Depending on what else you need your processor to do it may not be the best solution however. This code runs on an LPC2000 series processor from NXP.

/**********************************************************************/
/* Timer.c                                                            */
/* Implements a delay :                                               */
/*   TMR0 is a mcrosecond timer capable of timing events of upto      */
/*   4294.967295 seconds (1 hour 11 min 36.967295 sec)                */
/*   includes both delay and stop watch functions                     */
/*       void Delay(unsigned int delay); delay in microseconds        */
/*   Does not use interupts.  Note timer may rollover during delay    */
/*   so code checks for this                                          */
/*   Note: delay is minimum delay as interupts can slow it down       */
/**********************************************************************/
/*
 * Note: Assumes TMR0 is already setup with 1 microsecond tick
 */

#include <LPC2103.h>

#include "Timer.h"

void Delay(unsigned int delay){
    unsigned int start;
    unsigned int stop;
    unsigned int now;

    start = T0TC;
    stop = start + delay + 1;           /* +1 because call could arrive just
                                       before TOTC changes */
    if (stop > start){                /* usually is */
        do{
            now = T0TC;
        }while (now < stop && now >= start);  /* Catch timer roll-over as done */
    }else{                                    /* Need timer to roll over */
        do{
            now = T0TC;
        }while (now < stop || now >= start);  
    }
}

Even if you are happy to just sit in a loop waiting for a delay a timer may better as its more difficult to estimate delay times with a simple loop such as

for(i=1000; i >0; i--){
    ;
}

Because a good optimising compiler may just optimise this out.

Even it it does not get optimised its difficult to know exactly how long this delay will take because the NXP LPC series processors have memory accelerators and the processor has pipe lining.