PIC MCU: Software or hardware delay?

Question

Experimenting with blinking LEDs, I learned about creating delays with either a software loop or a timeout from a timer. I know that for a simple blinking LED program, where the processes aren't that complicated and timing isn't crucial, using either wouldn't matter. But in more of a time-crucial multitasking context what are the benefits and/or disadvantages of both?

Thanks heaps, here's how I set them up:

Software delay:

void softwaredelay()
{
    int i;
    for(i=0; i<1000; i++)
    {/*Timer Stuff*/}
}

Hardware delay (specific for PIC16 mcu's):

void timerdelay()
{
    OPTION_REGbits.PSA = 0;
    OPTION_REGbits.PS.  = 0b111;
    OPTION_REGbits.T0CS =  0;

    INTCONbits.T0IF = 0;
    TMR0 = 0b11111000;
    INTCONbits.T0IE = 1;

    while(INTCONbits.T0IF==0)
    {/*Timer Stuff*/}
}

Answer 1

You need to go to the bank (which is just around the corner) and do your laundry. Going to laundry requires you to wait for the washer to finish, and then wait for the the dryer to finish.

How would you go about performing these tasks?

On a lazy day, you could just do the laundry and then go to the bank. It's not that important. Who cares.

But on a busy day, where you have other things to do, like catching a movie, or studying or whatever task, the efficient thing to do is you load the first part of the laundry, then go to the bank, then load the second part of the laundry. Now you are free to do other things. That is maximizing your time so you can do other tasks.

Now for a microcontroller or any embedded system, the same is true. If you don't care about power, time, or anything, then go with a software-driven delay. It's easier to implement, and you can scale it as high as you want with great ease.

If you care about power, time, or efficiency, then a hardware timer is the way to go. While you wait you can either go to sleep or perform another task. It's a bit more complicated to setup, and if multiple tasks require delays, you may run out of hardware timers and then have to resort to a more complicated system of managing time and delays.

If you care about anything other than ease of use: Hardware Timer

If you care only about ease of use: Software

Answer 2

It largely depends on what you want to achieve.

For a software blocking delay like you have set up, you will not be able to service interrupts and maintain a constant interval. If you add more code into the loop the delay will change, potentially unpredictably or inconsistently if you have variable control flow blocks. I suspect that none of this matters much for a simple blinky program, but you asked about time critical applications

Answer 3

The "software delay" is a naive solution. You should never use such code in any microcontroller program because there is never a reason to do so: you will always have hardware timers. "Software delays" is unprofessional, since it has the following problems:

• Blocks the CPU from doing anything useful.
• Timing is very inaccurate and depends on how the C code gets translated to machine code. Writing reliable "software delays" requires you to disassemble the C code and check CPU ticks per assembler instruction. Quite tedious and has to be done over and over, as soon as the code or compiler options are changed.
• Interrupts will also make the timing inaccurate.
• The delay depends on the system clock. If the clock is changed, the delay will change too.
• The optimizer might remove the whole "software delay" code if it finds out that it does nothing. You might need various clever tricks to prevent this from happening.
• Keeps CPU current consumption at 100%.

If blocking the CPU is not an issue, that is if your program has nothing useful to do while waiting, then you should setup a hardware timer and poll that timer flag as in your second example.

For harder real-time requirements, you will have to use timer interrupts.

If current consumption is an issue and the MCU supports sleep/wake-up, you can usually configure the MCU to go into sleep mode until the timer has elapsed.