Foreground vs. Background (Nomenclature Question)

There are ISRs (interrupt service routines), and software that is not part of an ISR.

One of those is foreground, and one is background.

But, which is which?

What is the right nomenclature?

What is the definitive reference for the right nomenclature?

Thanks, Dave.

Reply to
David T. Ashley
Loading thread data ...

OK, we'll take that as read.

ISRs are background.

ISRs are background. Everything else is foreground.

This posting.

--
Grant Edwards                   grante             Yow!  Are BOTH T.V.S on??
                                  at               
 Click to see the full signature
Reply to
Grant Edwards

Yes, that's the usage under Unix.

In my experience it's fairly common to refer to ISRs as running "in the background" on embedded systems.

--
Grant Edwards                   grante             Yow!  I need "RONDO".
                                  at               
 Click to see the full signature
Reply to
Grant Edwards

What you're talking about is correct in the context of Unix, where foreground/background have specific meanings, but incorrect in the context of embedded.

As Grant said, ISRs are considered background in embedded. The main code is considered foreground.

Steve

formatting link

Reply to
Steve at fivetrees

Neither is. A foreground job is a text editor, or even the UNIX/Linux/whatever shell, which receive keyboard or other input. Background jobs cannot do this. If you logout, the foreground job is terminated, but a background job is not. And yes, you can move foreground jobs to the background and background jobs to the foreground. But, again, it has nothing to do with ISRs/not ISRs.

~Dave~

Reply to
Dave

Agree with Grant. The assumed context of the discussion, given the newsgroup, is embedded systems not an OS with someone running a shell.

For a non-rtos system, whatever isn't interrupt-driven is the foreground. For an rtos system things might get a little more foggy. I suppose you could argue that either the current task or the scheduler was the foreground though I'd go with the current task.

Reply to
Jim Stewart

Many embedded systems (and almost all of mine) are OS-less.

Yes, that's what I'd expect - in the context of embedded. It's not just me; it's common parlance amongst all the embedded guys I've ever worked with. But I'd agree it is a nebulous term that gets used in all sorts of other ways too.

Heh ;).

Steve

formatting link

Reply to
Steve at fivetrees

Hmmm. I have _never_ heard foreground/background used in reference to embedded systems. So, first to the library. In Operating Systems, H. Lorin and H.M. Deitel, in a discussion of real-time software (p. 71):

Foreground and background represent the preferences for system c Foreground is another problematic word. For a large segment of the IS world it means the operator interface, whereas background could mean serial communications, and other potentially high-speed activities. To me, this is a useless definition for embedded systems. The foreground is what is most important and that is the interrupt-driven, device-serving part of the system.

He provides a figure showing ISRs as foreground and tasks as background. Entry eight points to

formatting link
where Jack Ganssle quotes Perri Matthews:

The reason was that we were doing I/O accesses in our interrupt service routines! So even though the foreground code was hosed, the interrupts were still working and keeping the watchdog happy.

And later:

Then if the foreground code gets stupid, it will stop setting the flag, and the background will eventually give up and let the WDT do its thing to bring the system back on track.

He is using background to refer to ISRs.

I give up. I would choose foreground for ISRs since they do pre-empt normal code. I will happily go back to _not_ using those two words in relation to embedded systems! :-))

~Dave~

Reply to
Dave

Thanks for the replies. So, there are two possible answers, and I have credible posts arguing each. That really clears things up!

Yeah, this is a problem, and why I posed the question.

Using the definition that the background runs when the foreground has nothing to do ... then ISRs are foreground and non-ISR is the background. From a logical point of view (i.e. scheduling priority), I agree with this definition the most.

I think ISR and non-ISR (or nISR) might be the best nomenclature ... foreground and background are problematic.

Dave.

Reply to
David T. Ashley

Ok, where I live ISR's are the foreground as they are time critical and must be completed within a certain time, everything else that is not time critical goes into background.

Background is just a big list of call statements, when completed, starts over in an endless loop.

Foreground interrupts background as needed to complete time critical tasks.

Reply to
steve

I've been doing embedded stuff for 25 years, and I've heard it a lot.

Never heard it used like that.

Nope. I've never heard anybody use it that way in embedded systems.

So the forground was the non-interrupt stuff. That's the usage I've always heard.

The ISR stuff was the background.

Yup. That's the usage I've always heard. Perhaps it's regional?

I generally call ISRs "ISRs". If I'm using multitasking, I call the tasks "tasks" or "threads". I have occasionally heard the "idle" task that runs when everything else is blocked referred to as a "background" task. I usually just call it the "idle" task.

--
Grant Edwards                   grante             Yow!  if it GLISTENS,
                                  at               gobble it!!
 Click to see the full signature
Reply to
Grant Edwards

I'd disagree. I'm not convinced foreground/background relates to "having nothing to do" in embedded terms. Does turning off interrupts mean there is no foreground? Is main() a background task?

Consider an alternative: foreground is the main program. Background is stuff that happens "out of sight" while the foreground runs merrily on...

Once again, embedded often has little to do with OS principles e.g. scheduling priorities - and ISRs have little to do with scheduling as such, except in the very special case of a preemptive multitasker, which is not common in pure embedded work, and even then only as part of a scheduling management system: ISRs are only rarely the tasks themselves.

Can't argue with that ;).

Steve

formatting link

Reply to
Steve at fivetrees

Perhaps we can think of it as a matter of visibility and control.

In my embedded applications, the foreground (main loop) has control of the application. It presents the user interface and controls the sequence operations. It is the code most 'visible' to the user. I think of this as the foreground code.

In the background are the ISRs that that handle some of the I/O and present data to the foreground using queues or other data structures. That code is in the background because it handles I/O in a manner invisible to the user interface.

The foreground code controls the ISRs. It sets them up and can disable interrupts if required. The background (ISRs) generally don't exert any control over the foreground code. They simply provide data at the convenience of the foreground code.

I realize that it gets more complex when using a preemptive RTOS. I realize this because I spent a bunch of time with FreeRTOS on an ARM chip last week! ;-)

Mark Borgerson

Reply to
Mark Borgerson

True if you a running on a PC but this is comp.arch.embedded and here it means something completely different.

Ian

Reply to
Ian Bell

IME any interrupt is the foreground and whatever runs when there are no interrupts to service is called the background.

However, AFAIK there is no generally accepted definition and many people will define them the opposite way round.

Ian

Reply to
Ian Bell

Ditto and for 30 years.

Ian

Reply to
Ian Bell

Nope, they are foreground.

Nope, everything that runs outside and interrupt is background.

Nope, this correction ;-)

Ian

Reply to
Ian Bell

Foreground and background are relative terms, it depends on where you're standing.

  1. If you're inside an isr, then the main loop is running in the background, standing behind you, ready to take over when you're done.
  2. From the perspective of the main loop, the isr's are going on elsewhere, doing their own thing, out of sight, in the background.

But software is generally viewed from the perspective of the main loop (it's called main() for a reason). So the latter of the above two viewpoints is probably more relevant.

Dan

Reply to
Dan N

Yes, it means something completely different to you than to Steve and Grant. :-/

A PC can't be embedded? I'll have to talk to some of our test equipment manufacturers and tell them to yank those Windows-running hunks out of their boxes.

Also, thanks to _my_ 25+ years of embedded systems experience, I suspect I have a little broader definition of "comp.arch.embedded" than you at the high end. Probably caused in some small part by my architecting the addition of a _fifth_ Cray C90-16 to an existing cluster of four. And it very definitely was an embedded system. ;-)

~Dave~

Reply to
Dave

You're ignoring non-maskable interrupts (e.g., level 7 on the 68k family). How do they fit into your rationale? I just had to ask, Mark. ;-)

The idea of the "foreground" code controlling the ISRs, and disabling them, probably just sent a few real-time/embedded engineers to the medicine cabinet for aspirin and Tums--or to the liquor cabinet. :-)

~Dave~

Reply to
Dave

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.