what is the use of empty while loop in embedded programming?

[khatus]

what is the use of empty while loop in embedded programming?

e.g while(test expression);

actually i can't understand one line from this code

/*
Generating a delay of 1 ms in PIC18F4550 using Timer1
www.electronicwings.com
*/

#include "osc_config.h"        /* Configuration header file */
#include <pic18f4550.h>        /* Contains PIC18F4550 specifications */

#define Pulse LATB          /* Define Pulse as LATB to output on PORTB */

void Timer1_delay();

void main()
{
    OSCCON=0x72;          /* Configure oscillator frequency to 8MHz */
    TRISB=0;              /* Set as output port */
    Pulse=0xff;          /* Send high on PortB */
 
    while(1)
    {
        Pulse=~Pulse;          /* Toggle PortB at 500 Hz */
        Timer1_delay();      /* Call delay which provide desired delay */ 
    } 
}

void Timer1_delay()
{
    /* Enable 16-bit TMR1 register, No pre-scale, internal clock,timer OFF */
    T1CON=0x80;

    TMR1=0xf830;        /* Load count for generating delay of 1ms */
    T1CONbits.TMR1ON=1;      /* Turn ON Timer1 */
  while(PIR1bits.TMR1IF==0);     /* Wait for Timer1 overflow interrupt flag */
    TMR1ON=0;              /* Turn OFF timer */
    TMR1IF=0;              /* Make Timer1 overflow flag to '0' */
}



please explain the line "For ex: this type of while loop (without body) is used in wait & signal simaphore. "

I guess ..

Timer1 starts count from 0xf830. When it reaches 0xffff and overflows it makes TMR1IF=1.At the time of counting (i.e from 0xf830 to 0xffff) the empty while loop Wait for Timer1 overflow interrupt flag. When the overflow interrupt flag is high, the empty while loop fails .And the code continue executing the next line i.e

TMR1ON=0; /* Turn OFF timer */
TMR1IF=0; /* Make Timer1 overflow flag to '0' */

Please correct me if i am wrong...

[rjp]

yes.

some languages would expect a noop, like the "pass" in python to signify the "do nothing" in the wait until the condition turns true.

[SiliconWizard]

It will just wait until the condition becomes true.

[chickenHeadKnob]

In english this is called a "busy" wait. The cpu does nothing but loop polling for a condition, then exits.

[hendorog]

Completely off topic, but :- humorously I have seen this quite a few times in non embedded programming.

Everything works fine on the developers workstation, but when the program is run on a shared server it all turns to custard. Convincing them it is their program is the first problem...

This is because while the wait is spinning away waiting for the user to click OK or whatever the criteria is, it is consuming 100% of a core of the CPU. Get a few people using such a program and the server drops to its knees when several happen to get to the that point in the program.

I wouldn't go so far as to blame embedded programmers who have escaped to the dark side as its mostly seen in MS Access and VB apps. If you see a core at 100% for no reason this is very often the culprit.

A dirty hack is to stick a sleep in the loop, even a few ms sleep will radically improve things.

[ajb]

It's generally a good idea to include a timeout mechanism in wait loops, otherwise error conditions can cause the system to just sit there forever waiting for an event that never happens. 

Of course a fundamental problem in many embedded applications is "okay, something went wrong.  What can you do about it?" So sometimes the right answer is to wait for the watchdog to reset the device and maybe then it will work.

[bitseeker]

I guess ..

Timer1 starts count from 0xf830. When it reaches 0xffff and overflows it makes TMR1IF=1.At the time of counting (i.e from 0xf830 to 0xffff) the empty while loop Wait for Timer1 overflow interrupt flag. When the overflow interrupt flag is high, the empty while loop fails .And the code continue executing the next line

Correct. The while statement has no body because the PIC doesn't need to do anything until the overflow occurs. So, it just keeps checking the condition to determine when it can proceed to the next statement.

Of course, as hendorog pointed out, you have to be sure that a tight loop like this is appropriate for the platform and environment. Implementing it in the wrong one could be catastrophic for performance, power consumption, etc.

[mfro]

Maybe worth mentioning that this will - with any reasonably optimizing compiler - only work  if the variable you wait to change is declared volatile.

[bd139]

This sort of stuff is only good for extremely short waits measured in low cycle counts. Usually better to set up an interrupt on timer and sleep the CPU.

Last thing I did on AVR, through judicious sleeps and adding a scheduler, managed to get average current consumption down to 80uA over ten minutes.

[bitseeker]

Yep. I haven't worked with PIC before, but one would hope that you could have an ISR called when a condition, such as a particular overflow, occurred.

[mikeselectricstuff]

This sort of stuff is only good for extremely short waits measured in low cycle counts. Usually better to set up an interrupt on timer and sleep the CPU.

Applicability is entirely application dependent, so "usually better" is meaningless.
You may not care about power draw.
You may need fast continuation once the condition is met.
You may have other interrupt tasks.

[westfw]

but one would hope that you could have an ISR called when a condition, such as a particular overflow, occurred.

Interrupts are great.  If you use interrupts, you can have your empty while loop sit around and wait for a variable to be changed by the ISR, instead of waiting for a bit to change in the IO register...

 :-)

[mikeselectricstuff]

but one would hope that you could have an ISR called when a condition, such as a particular overflow, occurred.

Interrupts are great.  If you use interrupts, you can have your empty while loop sit around and wait for a variable to be changed by the ISR, instead of waiting for a bit to change in the IO register...

 :-)

At which point you realise that a polled loop and state machine(s) is often a more useful architecture.
 

[bd139]

Same as select / epoll on unix. Works wonders.

This sort of stuff is only good for extremely short waits measured in low cycle counts. Usually better to set up an interrupt on timer and sleep the CPU.

Applicability is entirely application dependent, so "usually better" is meaningless.
You may not care about power draw.
You may need fast continuation once the condition is met.
You may have other interrupt tasks.

Fair points.

[rrinker]

Completely off topic, but :- humorously I have seen this quite a few times in non embedded programming.

Everything works fine on the developers workstation, but when the program is run on a shared server it all turns to custard. Convincing them it is their program is the first problem...

This is because while the wait is spinning away waiting for the user to click OK or whatever the criteria is, it is consuming 100% of a core of the CPU. Get a few people using such a program and the server drops to its knees when several happen to get to the that point in the program.

I wouldn't go so far as to blame embedded programmers who have escaped to the dark side as its mostly seen in MS Access and VB apps. If you see a core at 100% for no reason this is very often the culprit.

A dirty hack is to stick a sleep in the loop, even a few ms sleep will radically improve things.

 This was quite common in the days before pre-emptive multitasking became the norm. Most MS-DOS programs assume they would be the only thing running on the box, which was fine for individual user workstations, but then when multiuser technology like Citrix started to become available, it caused problems. Had one client that had this issue - their primary application was written in dBase. While waiting for input, dBase just executed a tight loop, polling for keyboard activity. Worked great at first, then we added the second store to the system, and now it was useless, because the first user was consuming 100% of the CPU on a system that should have supported 16 or more users easily. There was a separate utility available to fix this, called Tame. It would force a looping application like that to give up the CPU. When we added this, now the beefy (for the time) server was easily able to handle the simultaneous access by a dozen stores (app was POS using thing clients, they got custom color-coded keyboards for them to make it easier to access each function of the application, and then they each had a receipt printer, and a trigger for the cash drawer. Wouldn;t surprise me if they are actually still using this, some 20+ years later.

[tggzzz]

but one would hope that you could have an ISR called when a condition, such as a particular overflow, occurred.

Interrupts are great.  If you use interrupts, you can have your empty while loop sit around and wait for a variable to be changed by the ISR, instead of waiting for a bit to change in the IO register...

 :-)

At which point you realise that a polled loop and state machine(s) is often a more useful architecture.

Very true, and it neatly segues into that other thread:
https://www.eevblog.com/forum/microcontrollers/state-machines-is-this-topic-taught-any-more/msg1931161/#msg1931161

[brucehoult]

Maybe worth mentioning that this will - with any reasonably optimizing compiler - only work  if the variable you wait to change is declared volatile.

If PIC's headers don't declare hardware registers as volatile then something is very wrong :-)

[mfro]

Maybe worth mentioning that this will - with any reasonably optimizing compiler - only work  if the variable you wait to change is declared volatile.

If PIC's headers don't declare hardware registers as volatile then something is very wrong :-)

Agreed. But who said you can use polling while loops with PIC hardware registers only?

[SiliconWizard]

but one would hope that you could have an ISR called when a condition, such as a particular overflow, occurred.

Interrupts are great.  If you use interrupts, you can have your empty while loop sit around and wait for a variable to be changed by the ISR, instead of waiting for a bit to change in the IO register...

 :-)

 

A better mechanism (only if you really need it, which is not always the case!) would be to allow other portions of code to execute while a specific code portion is "waiting" (which is akin to multithreading), which suddenly makes matters a lot more difficult. You can often achieve that by some kind of cooperative multitasking (instead of resorting to more complex to handle preemptive multitasking).

If there's no other task to handle than waiting, putting the processor to sleep (if the processor has options for that) instead of running a loop is a good idea to save energy as long as the wake-up time is compatible with your requirements - that may or may not be the case.