3

A feasible way to achieve a suitable time delay is to use busy-waiting, however what are the advantages and disadvantages of using a busy-waiting or timer interrupts approach programming?

M.Khalaf
  • 75
  • 1
  • 9
  • I am not sure what _busy-waiting_ is. Can you post an example code snippet in your question? – ryyker Jan 12 '16 at 20:33
  • 1
    Busy waiting is the process of waiting in a loop and continuously checking until a certain condition is met, in order to move on to the next process. – M.Khalaf Jan 12 '16 at 20:38

3 Answers3

3

There are probably many, I will try to address what seems most important to me.

Advantages of busy-waiting:

  • The execution flow is usually easier to comprehend and thus less error prone.
  • Timing can be determined more accurately in some cases

Disadvantages:

  • No other code (except perhaps other interrupt routines) can be executed.
  • CPU-time is wasted: If no other work must be processed it is still more efficient to set some powersaving-state and let a timer interrupt wake it up in time.
Ctx
  • 18,090
  • 24
  • 36
  • 51
  • If you'd like to ask for clarification on the answer, please do so. If you'd like to claim it's a 'bad' answer, then give what you consider to be a 'good answer' as your answer. If you want to engage in an argument and name calling; this isn't the place for that. – George Stocker Jan 12 '16 at 21:06
  • Hi thank you for your answer, however could you please provide me more advantages of the busy-waiting process? – M.Khalaf Jan 13 '16 at 12:26
2

A disadvantage of busy-waiting in embedded devices is the increased power consumption. In a busy wait, the processor is running full-blast, consuming power with no result. Most low power processors have the ability to put the processor to sleep while waiting for a timer interrupt, reducing power consumption dramatically. Lower power consumption = longer battery life.

AShelly
  • 34,686
  • 15
  • 91
  • 152
2

Unless you have nothing else to do in your application or the result needs to be handled immediately (which is rather rare), you don't want to busy wait. It eats up cycles that could be used doing something else or sleeping.

A simple example is let's say you're making a wifi thermostat that communicates to a wifi chip via UART. Your application will need to read and process the temperature, update when new data is available, send out wifi messages, receive wifi messages and receive updates from button pushes just to name a few. If you ware busy waiting for any one of these to happen, than your thermostat can't do anything else unless it is though interrupt.

Dom
  • 1,687
  • 6
  • 27
  • 37
  • The decission is not that simple. There might be good reasons to use polling, e.g. reliability or fixed cycle times. An event-driven approach might require quite some overhead to provide similar stability. But as always: it depends. – too honest for this site Jan 12 '16 at 20:49
  • You can poll for something that's fine, but that isn't necessarily busy-waiting. In my example you could just poll the temperature any time you want, but you wouldn't want to sit in a busy while or for loop until it's either changed or for a certain amount of time to go by nor would you typically want to sit and wait for a response after sending message. That is wasteful and there is a lot more you can do. – Dom Jan 12 '16 at 20:55
  • With polling typically waiting for a flag is meant. That flag signals an event the CPU has to react to. This is commonly called busy-waiting. Typically you have a large loop of state-machines which poll certain flags and advance accordingly. There is not necessarily a single flag which blocks the CPU completely. A GUI-application main event loop could be such a typical example. Although there are better and more modern approaches. But as I wrote: it is not all black and white. No offence, but have you ever programmed embedded systems beyond blinking an LED? – too honest for this site Jan 12 '16 at 21:02
  • @Olaf yes I've designed whole systems... I think you aren't really getting what I'm saying in this. Don't [busy wait](https://en.wikipedia.org/wiki/Busy_waiting) do other useful things while you wait don't just block until the event has resolved. – Dom Jan 12 '16 at 21:08
  • And I say there are good reasons to have a central polling loop and busy-wait. You might have just not worked in a field this is very well useful. And it does not necessarily increase power consumption on the proper hardware and if done correctly. From a system-view, actually, every task-based RTOS implements a kind of busy-waiting. That's what the idle-task is for. (and using a special instruction like ARM `WFI`/`WFE` does not change the semantics). Actually there are only few systems which don't implement some kind of busy-waiting at some level. – too honest for this site Jan 12 '16 at 21:16