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.

On 2006-06-08, David T. Ashley <dta@e3ft.com> wrote:

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
visi.com

On 2006-06-08, Dave <dave@comteck.com> wrote:
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
visi.com

"Dave" <dave@comteck.com> wrote in message
newsan.2006.06.08.22.32.08.953618@comteck.com...
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
http://www.fivetrees.com

On Thu, 08 Jun 2006 17:11:43 -0400, David T. Ashley wrote:

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~

Grant Edwards wrote:

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.

"Dave" <dave@comteck.com> wrote in message
newsan.2006.06.09.00.42.50.310622@comteck.com...
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
http://www.fivetrees.com

On Thu, 08 Jun 2006 22:38:50 +0100, Steve at fivetrees wrote:

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 control
that the application is given. A pure background application receives
the processor only when there is no work for the foreground to do and
loses the processor whenever work arrives for the foreground.

I would infer ISRs as foreground from this, but YMMV. So, to google we
go: embedded+foreground. Entry number two points to
www.smxinfo.com/articles/lsr_art/lsr_art.htm where Ralph Moore, talking
about the smx RTOS says:

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 www.ganssle.com/tem/tem86.pdf, 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~

"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote in message
news:mbqdnXus4OjwJhXZRVnyqQ@pipex.net...
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.

David T. Ashley wrote:
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.

On 2006-06-09, Dave <dave@comteck.com> wrote:

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!!
visi.com

"David T. Ashley" <dta@e3ft.com> wrote in message
news:UH4ig.7345$cL3.2722@fe12.usenetserver.com...
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
http://www.fivetrees.com

In article <1149822069.495282.17650@j55g2000cwa.googlegroups. com>,
bungalow_steve@yahoo.com says...

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

Dave wrote:

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

Ian

David T. Ashley wrote:

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

Grant Edwards wrote:

Ditto and for 30 years.

Ian

Grant Edwards wrote:

Nope, they are foreground.

Nope, everything that runs outside and interrupt is background.

Nope, this correction ;-)

Ian

On Thu, 08 Jun 2006 17:11:43 -0400, David T. Ashley wrote:

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

On Fri, 09 Jun 2006 07:55:45 +0100, Ian Bell wrote:

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~

On Thu, 08 Jun 2006 21:33:53 -0700, Mark Borgerson wrote:

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~