# Software delay vs hardware timers

Working with a micro controller, on which exact conditions should we choose between Hardware timers and Software delays on an Embedded Controller?

I have seen articles which do emphasize on use of timers.

If timers are so good then why is Software delays needed?

This is the link that describes the usage of s/w or hardware timers.

http://betterembsw.blogspot.in/2012/12/software-timing-loops.html

But this does not emphasize on the case when h/w timers are available on the controller that we are using.

-
What purpose is the delay - without this info this question is too broad to answer. –  Andy aka Mar 20 '14 at 12:54
You need to clarify what you mean by both software and hardware delays. Delays in software can be just simple loops or may rely on a hardware timer either by waiting for a particular value or through the use of interrupts. Perhaps a link to the articles you mention may help. –  Warren Hill Mar 20 '14 at 13:00
Generally, hardware costs money per unit plus NRE and software costs only NRE, so normally software is preferred, provided it works well enough to meet specifications. –  Spehro Pefhany Mar 20 '14 at 13:04
@SpehroPefhany - I'd say given the (admittedly vague) question states "working with a microcontroller", if you have a micro and it has hardware timers, it's usually desirable to use them where practical in preference of writing more software. –  John U Mar 20 '14 at 18:31
@Rookie91 If you mention some articles which you have seen and which are relevant to your post, then please provide links. This would make better context for your question. –  Nick Alexeev Jun 7 '14 at 19:14

By hardware delays I meant 'Timers'.

The advantage of using timers to realize a delay is that they provide a way to allow async counting. Using a "Software delay" you force the controller to put all its resources into processing some kind of loop (incrementing a variable until a given value) and thus blocking the rest of the code execution path.

If hardware delay is so good then why is Software delays needed?

A software delay is easier to implement and may be sufficient if its just a very short delay which is not significantly interrupting any other task in the main sequential code processing path. Furthermore, the timers may be in use for some other hardware related tasks like PWM generation and may not be "free" to be configured according to your delay requirements.

Another use case would be some initial delay that is required before the main loop is running. There would be no need to use a hardware delay in that case.

One last thing that comes to mind is that a software delay doesn't require interrupts to be globally enabled, while its a requirement for timer based delays (at least for the common use case).

-
You dont NEED an interrupt for a timer delay. You can certainly sit at one line and poll the timer value. You lose many of the benefits of using a timer, but you don't need the interrupt. IIRC, in fact, STM timers can set a flag when you've reached your target time, so you can just poll the flag without even polling the timer count. –  Scott Seidman Mar 20 '14 at 13:57
@ScottSeidman: True, I supplemented that its a "requirement" for the common use case. –  Rev1.0 Mar 20 '14 at 19:15

Where possible I would normally use a timer a software delay for the following reasons

• A timer based delay time is easy to calculate as you know how long a tick lasts. A software delay may be optimised out if your compiler is too clever or since a lot of modern processors use a pipeline its difficult to calculate precisely the amount of time a simple software loop will take.

• You can often use a timer to generate an interrupt so can get on with other tasks.

When wouldn't I use a timer?

• If I didn't have one spare

• If I needed a really short delay like for example setting some output port lines for a specific address then pulling another line low to signify I want to read data. Such a delay may be as short as a few clock cycles so there would be no benefit in using a timer.

-

Hardware timers are very precise, but there is usually a limited number of them available. Software timers just consume CPU cycles and memory space, which are the only limits on the number that you can have.

One compromise that is used on many systems is to set up one hardware timer to generate a precise periodic "tick" interrupt at a known rate, and then implement an arbitrary number of software timers (whose resolution is the tick period) based on that interrupt.

Tick rates vary, anywhere from the 18.20651 Hz[1] used on the original IBM PC, to 10 kHz or more in some embedded real-time systems.

[1]The precise value is $\frac{7166250}{393609.216} Hz$. Brownie points to the first person who can fully explain where this number comes from.

-
Pretty sure it has to do with color TVs... :) –  Adam Lawrence Mar 20 '14 at 15:02
I thought the system clock was 14.31818MHz - four times the NTSC color carrier needed to generate the color burst so a TV could be used as the monitor. This 14MHz clock was divided by 3 to give the processor its 4.772727MHz clock, which was divided by 4 to feed the system counter/timer at 1.193182MHz, and rolls over at 65,536 to give DOS its 18.20651Hz tick. I'm not sure how that relates to your equation, $\frac{7166250}{393609.216} Hz$, though. IBM XT Technical Reference page 1-4. –  Adam Davis Mar 20 '14 at 15:04
@AdamDavis: Nearly there! Where does the 14.31818 MHz number come from? –  Dave Tweed Mar 20 '14 at 15:08
@DaveTweed Is this another "horses rear end --> rocket booster diameter" story? Colorburst frequency. –  Adam Davis Mar 20 '14 at 17:02
Exactly. It all stems from the original black-and-white TVs having their vertical frequencies locked to the power-line frequency of 60 Hz, so that power-line interference would stand still on the screen. $$60 Hz\cdot\frac{525}{2}\cdot\frac{1}{1.001}\cdot\frac{455}{2}\cdot \frac{4}{3}\cdot \frac{1}{4} \cdot\frac{1}{2^{16}} = 18.20651 Hz$$ –  Dave Tweed Mar 20 '14 at 17:47