Foreground vs. Background (Nomenclature Question)

[David T. Ashley]

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.

[Grant Edwards]

Post by David T. Ashley
There are ISRs (interrupt service routines), and software that
is not part of an ISR.
One of those is foreground, and one is background.

OK, we'll take that as read.

Post by David T. Ashley
But, which is which?

ISRs are background.

Post by David T. Ashley
What is the right nomenclature?

ISRs are background. Everything else is foreground.

Post by David T. Ashley
What is the definitive reference for the right nomenclature?

This posting.

[Ian Bell]

Post by Grant Edwards

Post by David T. Ashley
There are ISRs (interrupt service routines), and software that
is not part of an ISR.
One of those is foreground, and one is background.

OK, we'll take that as read.

Post by David T. Ashley
But, which is which?

ISRs are background.

Nope, they are foreground.

Post by Grant Edwards

Post by David T. Ashley
What is the right nomenclature?

ISRs are background. Everything else is foreground.

Nope, everything that runs outside and interrupt is background.

Post by Grant Edwards

Post by David T. Ashley
What is the definitive reference for the right nomenclature?

This posting.

Nope, this correction ;-)

Ian

[Dave]

Post by David T. Ashley
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?

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]

Post by Dave

Post by David T. Ashley
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?

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.

Yes, that's the usage under Unix.

Post by Dave
But, again, it has nothing to do with ISRs/not ISRs.

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

[Jim Stewart]

Post by Grant Edwards

Post by Dave

Post by David T. Ashley
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?

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.

Yes, that's the usage under Unix.

Post by Dave
But, again, it has nothing to do with ISRs/not ISRs.

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

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.

[Anton Erasmus]

Post by Grant Edwards

Post by Dave

Post by David T. Ashley
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?

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.

Yes, that's the usage under Unix.

Post by Dave
But, again, it has nothing to do with ISRs/not ISRs.

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

It depends on where the "main" task is run. At work we refer to the
main task, which runs in a periodic timer ISR the foreground task,
and the test code, which runs when the ISR does not run the background
task. So IMO the code that defines the main task performed by the
embedded device is the foreground task, and other code that gets
executed because of interrupts, or because no interrupts are running
is the background tasks.

Regards
Anton Erasmus

[Ian Bell]

Post by Anton Erasmus

Post by Grant Edwards

Post by Dave

Post by David T. Ashley
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?

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.

Yes, that's the usage under Unix.

Post by Dave
But, again, it has nothing to do with ISRs/not ISRs.

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

It depends on where the "main" task is run. At work we refer to the
main task, which runs in a periodic timer ISR the foreground task,
and the test code, which runs when the ISR does not run the background
task. So IMO the code that defines the main task performed by the
embedded device is the foreground task, and other code that gets
executed because of interrupts, or because no interrupts are running
is the background tasks.

To my mind it is all to do with priorities. The highest priority running
task is the forground - which generally means an ISR, and whatever runs
when this is not running is the background.

Ian

[Steve at fivetrees]

Post by Ian Bell
To my mind it is all to do with priorities. The highest priority running
task is the forground - which generally means an ISR, and whatever runs
when this is not running is the background.

To repeat myself, I don't see any connection between task priorities and
foreground/background - in an embedded context.

And don't forget that the foreground (non-ISR) code can (usually) mask out
(background) ISRs. To my mind, this means that the foreground (main code) is
actually higher priority unless it explicitly decides to allow the
background ISRs to have a look in. Priorities shmiorities ;).

I guess you can call it what you like, but your usage would be contrary to
that of all the companies I've worked for/in during the last 3 decades.

Steve
http://www.fivetrees.com

[Ian Bell]

Post by Steve at fivetrees

Post by Ian Bell
To my mind it is all to do with priorities. The highest priority running
task is the forground - which generally means an ISR, and whatever runs
when this is not running is the background.

To repeat myself, I don't see any connection between task priorities and
foreground/background - in an embedded context.
And don't forget that the foreground (non-ISR) code can (usually) mask out
(background) ISRs. To my mind, this means that the foreground (main code)
is actually higher priority unless it explicitly decides to allow the
background ISRs to have a look in. Priorities shmiorities ;).

This is a design decision which, by masking ISRs, makes the non-ISR routines
a higher priority. To my mind this is a poor design decision in a real time
system - it may be OK elsewhere.

Post by Steve at fivetrees
I guess you can call it what you like, but your usage would be contrary to
that of all the companies I've worked for/in during the last 3 decades.

Experience clearly differs since my usage has been commonplace in all the
companies I've worked with/for in the same period.

Clearly there is no generally accepted definition.

Ian

[Dave]

Post by Ian Bell

Post by Steve at fivetrees
And don't forget that the foreground (non-ISR) code can (usually) mask out
(background) ISRs. To my mind, this means that the foreground (main code)
is actually higher priority unless it explicitly decides to allow the
background ISRs to have a look in. Priorities shmiorities ;).

This is a design decision which, by masking ISRs, makes the non-ISR routines
a higher priority. To my mind this is a poor design decision in a real time
system - it may be OK elsewhere.

Without using either of those two words (!), we do disable interrupts for
(hopefully) short periods of time in non-ISR code in automotive
controllers. It isn't because the code doing the disabling has a higher
priority, but because the code needs to perform a multiple instruction
sequence which needs to appear atomic. To the ISRs, it appears as though
a (really!) long instruction is executing. Is this a bad design decision?
I don't think so--there are some operations which simply must be performed
without being interrupted. This is normal in my experience (yy years ;-)
in the real-time, embedded world.

There is another class of operations which must be performed coherently
and are handled in other ways. For instance, some ADCs must be performed
within a certain time period for certain signals. Since some ADCs are
performed synchronously with engine events, the conversions of a coherent
group may be interrupted by the synchronous conversions. The ADC module
used has provisions to make a group of conversions coherent so that, if
interrupted on say the last of a group of three, when the ADC returns from
the synchronous conversions, it starts over at the beginning of the
interrupted coherent group.


~Dave~

[Ian Bell]

Post by Dave

Post by Ian Bell

Post by Steve at fivetrees
And don't forget that the foreground (non-ISR) code can (usually) mask
out (background) ISRs. To my mind, this means that the foreground (main
code) is actually higher priority unless it explicitly decides to allow
the background ISRs to have a look in. Priorities shmiorities ;).

This is a design decision which, by masking ISRs, makes the non-ISR
routines a higher priority. To my mind this is a poor design decision in
a real time system - it may be OK elsewhere.

Without using either of those two words (!), we do disable interrupts for
(hopefully) short periods of time in non-ISR code in automotive
controllers. It isn't because the code doing the disabling has a higher
priority, but because the code needs to perform a multiple instruction
sequence which needs to appear atomic. To the ISRs, it appears as though
a (really!) long instruction is executing. Is this a bad design decision?

No, but is needs to be done with great care.

Post by Dave
I don't think so--there are some operations which simply must be performed
without being interrupted. This is normal in my experience (yy years ;-)
in the real-time, embedded world.

Agreed.


Ian

[steve]

Post by Steve at fivetrees
And don't forget that the foreground (non-ISR) code can (usually) mask out
(background) ISRs. To my mind, this means that the foreground (main code) is
actually higher priority unless it explicitly decides to allow the
background ISRs to have a look in. Priorities shmiorities ;).

This wouldn't be allowed in real time life critical embedded
applications, the timing aspects of the code would simply be
unverifiable.

[Ian Bell]

Post by steve

Post by Steve at fivetrees
And don't forget that the foreground (non-ISR) code can (usually) mask
out (background) ISRs. To my mind, this means that the foreground (main
code) is actually higher priority unless it explicitly decides to allow
the background ISRs to have a look in. Priorities shmiorities ;).

This wouldn't be allowed in real time life critical embedded
applications, the timing aspects of the code would simply be
unverifiable.

Indeed which is why it is very difficult to use an RTOS (i.e.pre-emptive) in
critical applications. Many (standards for critical apps) insist on nothing
but polling, others will permit a time triggered cooperative scheduler to
be used as there is only ever one interrupt.

Ian

[Steve at fivetrees]

Post by steve

Post by Steve at fivetrees
And don't forget that the foreground (non-ISR) code can (usually) mask out
(background) ISRs. To my mind, this means that the foreground (main code) is
actually higher priority unless it explicitly decides to allow the
background ISRs to have a look in. Priorities shmiorities ;).

This wouldn't be allowed in real time life critical embedded
applications, the timing aspects of the code would simply be
unverifiable.

Most of my designs *are* real-time, critical (but not *formally*
life-critical) embedded applications - i.e. one where failing to make the
timing constraints would do damage to the company's reputation, but
hopefully not kill someone. (They're mostly industrial process control &
data acquisition apps.)

As Dave has said, one frequently does need to disable IRQs in order to make
certain operations atomic. In such cases the IRQ will be delayed, not
missed - and we usually have strict timings, usually dictated by the
hardware, on how long we can mask interrupts for.

Also we distinguish between different interrupt priorities - certain things
really can't be masked safely. Also certain IRQs may mask others. To put it
another way, one can still achieve the level of determinism necessary by
paying attention to IRQ priority - and not just by saying "thou shalt not
mask interrupts".

Where timing aspects need to be set in stone, I generally try to make this a
hardware (e.g. timer)-based system. (Example: I had a VCF-based ADC; a
counter counted the VCF output within a strict window. This was achieved by
gating the VCF output with a timer-derived window signal.)

Steve
http://www.fivetrees.com

[Steve at fivetrees]

Post by Steve at fivetrees
Also we distinguish between different interrupt priorities - certain
things really can't be masked safely. Also certain IRQs may mask others.
To put it another way, one can still achieve the level of determinism
necessary by paying attention to IRQ priority - and not just by saying
"thou shalt not mask interrupts".

Talking of which - in the case of nested interrupts, does the "ISR ==
foreground" view mean there are multiple foregrounds? Or is the
highest-priority IRQ the foreground, and the rest a part of IRQs the
background? Doesn't make sense to me - but it's nevertheless a sincere
question.

Steve
http://www.fivetrees.com

[Dave]

Post by Steve at fivetrees
Talking of which - in the case of nested interrupts, does the "ISR ==
foreground" view mean there are multiple foregrounds? Or is the
highest-priority IRQ the foreground, and the rest a part of IRQs the
background? Doesn't make sense to me - but it's nevertheless a sincere
question.

In the case of nested interrupts, does the "ISR == background" view
mean there are multiple backgrounds? Or is the highest-priority IRQ
the background, and the rest a part of IRQs the foreground? Doesn't
make sense to me - but it's nevertheless a sincere question. ;-)

Now I'll go back to not using those two words.

Even if they are not nested, multiple ISRs ( e.g., CAN, UART, Timer, ...)
exist in many (most?) systems. So whether you're an "ISR = 'f' word" or
"ISR = 'b' word" proponent, what do you do?


~Dave~

[Steve at fivetrees]

Post by Dave

Post by Steve at fivetrees
Talking of which - in the case of nested interrupts, does the "ISR ==
foreground" view mean there are multiple foregrounds? Or is the
highest-priority IRQ the foreground, and the rest a part of IRQs the
background? Doesn't make sense to me - but it's nevertheless a sincere
question.

In the case of nested interrupts, does the "ISR == background" view
mean there are multiple backgrounds? Or is the highest-priority IRQ
the background, and the rest a part of IRQs the foreground? Doesn't
make sense to me - but it's nevertheless a sincere question. ;-)
Now I'll go back to not using those two words.
Even if they are not nested, multiple ISRs ( e.g., CAN, UART, Timer, ...)
exist in many (most?) systems. So whether you're an "ISR = 'f' word" or
"ISR = 'b' word" proponent, what do you do?

I'm happy with the idea of "interrupts" (plural) being the background. I'm
less happy with the idea of them being, collectively, foreground.

Steve
http://www.fivetrees.com

[Ian Bell]

Post by Dave
In the case of nested interrupts, does the "ISR == background" view
mean there are multiple backgrounds? Or is the highest-priority IRQ
the background, and the rest a part of IRQs the foreground? Doesn't
make sense to me - but it's nevertheless a sincere question. ;-)

IMHO the currently running ISR is the foreground. Whatever runs when no ISR
is running is the background.

Ian

[steve]

Post by Steve at fivetrees
Talking of which - in the case of nested interrupts, does the "ISR ==
foreground" view mean there are multiple foregrounds? Or is the
highest-priority IRQ the foreground, and the rest a part of IRQs the
background? Doesn't make sense to me - but it's nevertheless a sincere
question.

In life critical applications that I have worked on, only one interrupt
is allowed (and it must be a synchronous interrupt), so the question of
nested interrupts never comes up. Everything else is polled. These
restrictions are necessary so that I can guarantee and prove (though
test or analysis) that a specific function will absolutely run within a
specific timeframe.

[Ian Bell]

Post by Steve at fivetrees

Post by steve

Post by Steve at fivetrees
And don't forget that the foreground (non-ISR) code can (usually) mask out
(background) ISRs. To my mind, this means that the foreground (main code) is
actually higher priority unless it explicitly decides to allow the
background ISRs to have a look in. Priorities shmiorities ;).

This wouldn't be allowed in real time life critical embedded
applications, the timing aspects of the code would simply be
unverifiable.

Most of my designs *are* real-time, critical (but not *formally*
life-critical) embedded applications - i.e. one where failing to make the
timing constraints would do damage to the company's reputation, but
hopefully not kill someone. (They're mostly industrial process control &
data acquisition apps.)
As Dave has said, one frequently does need to disable IRQs in order to
make certain operations atomic. In such cases the IRQ will be delayed, not
missed - and we usually have strict timings, usually dictated by the
hardware, on how long we can mask interrupts for.

I am aware of that. However, in critical systems it is preferable not to do
so as it makes the system less deterministic.

Post by Steve at fivetrees
Also we distinguish between different interrupt priorities - certain
things really can't be masked safely. Also certain IRQs may mask others.
To put it another way, one can still achieve the level of determinism
necessary by paying attention to IRQ priority - and not just by saying
"thou shalt not mask interrupts".

I did not say that,, but in critical systems there ways of doing just that.

IAn

[Steve at fivetrees]

Post by Ian Bell

Post by Steve at fivetrees
Also we distinguish between different interrupt priorities - certain
things really can't be masked safely. Also certain IRQs may mask others.
To put it another way, one can still achieve the level of determinism
necessary by paying attention to IRQ priority - and not just by saying
"thou shalt not mask interrupts".

I did not say that,, but in critical systems there ways of doing just that.

My post was in response to "steve" <***@yahoo.com>, as indicated
by the accreditisationificationage.

Steve
http://www.fivetrees.com

[Steve at fivetrees]

Post by Dave

Post by David T. Ashley
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?

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.

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

[Dave]

Post by Steve at fivetrees

Post by Dave
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.

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.

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]

Post by Dave
Hmmm. I have _never_ heard foreground/background used in reference
to embedded systems. So, first to the library. In Operating Systems, H.

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

Post by Dave
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
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.
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.

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.

Post by Dave
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! :-))

Heh ;).

Steve
http://www.fivetrees.com

[David T. Ashley]

Post by Steve at fivetrees
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.

Post by Dave
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! :-))

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.

[Steve at fivetrees]

Post by David T. Ashley
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'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.

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

Can't argue with that ;).

Steve
http://www.fivetrees.com

[Grant Edwards]

Post by Dave

Post by Steve at fivetrees
As Grant said, ISRs are considered background in embedded. The
main code is considered foreground.

Hmmm. I have _never_ heard foreground/background used in
reference to embedded systems.

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

Post by Dave
So, first to the library. In Operating Systems, H. Lorin and
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.

Never heard it used like that.

Post by Dave
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
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.

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

Post by Dave
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
The reason was that we were doing I/O accesses in our interrupt
service routines! So even though the foreground code was hosed,

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

Post by Dave
the interrupts were still working and keeping the watchdog happy.

The ISR stuff was the background.

Post by Dave
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.

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

Post by Dave
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! :-))

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.

[Ian Bell]

Post by Grant Edwards

Post by Dave

Post by Steve at fivetrees
As Grant said, ISRs are considered background in embedded. The
main code is considered foreground.

Hmmm. I have _never_ heard foreground/background used in
reference to embedded systems.

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

Ditto and for 30 years.

Ian

[TheDoc]

Post by Ian Bell

Post by Grant Edwards

Post by Dave

Post by Steve at fivetrees
As Grant said, ISRs are considered background in embedded. The
main code is considered foreground.

Hmmm. I have _never_ heard foreground/background used in
reference to embedded systems.

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

Ditto and for 30 years.
Ian

Ditto - Ditto.. for 27 years.

[Ian Bell]

Post by Dave

Post by David T. Ashley
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?

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.

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

Ian

[Dave]

Post by Ian Bell

Post by Dave
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.

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

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~

[Ian Bell]

Post by Dave

Post by Ian Bell

Post by Dave
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.

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

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.

Depends on your definition of embedded and PC. We used to build PCs into
robot systems but I would not call that embedded.

Post by Dave
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. ;-)

I doubt it since, if you want to compare dicks, I have been in embedded for
30+ years.

Ian

Post by Dave
~Dave~

[Dave]

Post by Ian Bell
I doubt it since, if you want to compare dicks, I have been in embedded for
30+ years.

Yes, we know, since that's the second time you've mentioned it in this
thread.


~Dave~

[Ian Bell]

Post by Dave

Post by Ian Bell
I doubt it since, if you want to compare dicks, I have been in embedded
for 30+ years.

Yes, we know, since that's the second time you've mentioned it in this
thread.
~Dave~

Well when you reach are age you often need to have things repeated ;-)

Ian

[CBFalconer]

... snip ...

Post by Ian Bell
Depends on your definition of embedded and PC. We used to build
PCs into robot systems but I would not call that embedded.

Post by Dave
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. ;-)

I doubt it since, if you want to compare dicks, I have been in
embedded for 30+ years.

My first embedded system was a hard wired computer. Later I
adapted my DAQ512 to automatically supervise and reduce the data
for Carbon 14 age measurements, combined with some Picker Nuclear
systems, involving least square fits. That was about 1968. See:
<http://cbfalconer.home.att.net/firstpc>

[Andy Sinclair]

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

I doubt many people who frequent this newsgroup consider a PC without
a screen or a supercomputer an embedded system.

[Grant Edwards]

Post by Andy Sinclair

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

I doubt many people who frequent this newsgroup consider a PC without
a screen or a supercomputer an embedded system.

Why not? If it's embedded in something and running nothing but
special purpose software, I consider it an embedded system.

[Steve at fivetrees]

Post by Grant Edwards

Post by Andy Sinclair

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

I doubt many people who frequent this newsgroup consider a PC without
a screen or a supercomputer an embedded system.

Why not? If it's embedded in something and running nothing but
special purpose software, I consider it an embedded system.

We've had this conversation once or twice before ;).

ISTR that we broadly agreed the following definitions:
- embedded product: microprocessor/microcontroller-based bespoke PCB
- embedded system: embedded PC-based

(I deal almost exclusively with the former.)

Steve
http://www.fivetrees.com

[Roberto Waltman]

Post by Grant Edwards

Post by Andy Sinclair
I doubt many people who frequent this newsgroup consider a PC without
a screen or a supercomputer an embedded system.

Why not? If it's embedded in something and running nothing but
special purpose software, I consider it an embedded system.

That is my view also. The embedded projects I have worked on range
from 8048 microcontrollers, to CDDI clusters of 14 "industrial grade"
rack mounted Pentium PCs with two X-terminals, with a few Vax and
other minis in between.
They were "embedded" in a larger system, and the software would have
been useless without the hardware to which these computers were
connected.

[Ian Bell]

Post by Grant Edwards

Post by Andy Sinclair

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

I doubt many people who frequent this newsgroup consider a PC without
a screen or a supercomputer an embedded system.

Why not? If it's embedded in something and running nothing but
special purpose software, I consider it an embedded system.

Precisely, that is YOUR definition, but many of us have a different
definition.

Ian

[steve]

Post by David T. Ashley
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.

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.

[Mark Borgerson]

Post by steve

Post by David T. Ashley
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.

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.

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

[Dave]

Post by Mark Borgerson
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.

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~

[Mark Borgerson]

Post by Dave

Post by Mark Borgerson
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.

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. ;-)

While I've done a lot of designs around M68K systems (and other systems
with NMI interrupts), I've NEVER connected NMI to a peripheral that
had no facility for disabling the pin connected to NMI. That may
be bypassing the spirit of the NMI, but I generally consider the
power plug or reset button to be the only truly non-maskable
events. I can envision safety-critical systems where NMI
would be useful. I cannot envision a system where that
interrupt could occur without some hardware initialization
by the foreground routine.

Post by Dave
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. :-)

I suppose that would depend on how the interrupts were controlled. When
I use interrupts, my 'foreground' code has to first set up the
peripherals to allow the interrupts to function. Depending on the
complexity of the interrupt hardware and software, the ISRs may not
allow nested interrupts---which is certainly control of a sort.

For example:

In an instrument which is processing analog input and
presenting data to the user, the foreground program accepts
a command, Sets up the ADC to collect the data in an ISR. While
the data is being collected the foreground routine monitors
the user input (for a 'cancel' command, etc.), checks the
status and keeps the user informed on the progress of the
data collection. When collection is finished, the foreground
routine disables the ADC and its interrupt, pulls the data
from the buffer that was filled by he ISR, and presents
it to the user.

Post by Dave
~Dave~

Mark Borgerson

[Dave]

Post by Mark Borgerson

Post by Dave
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. :-)

I suppose that would depend on how the interrupts were controlled. When
I use interrupts, my 'foreground' code has to first set up the
peripherals to allow the interrupts to function. Depending on the
complexity of the interrupt hardware and software, the ISRs may not
allow nested interrupts---which is certainly control of a sort.

Our automotive engine controllers do have nested interrupts. As part of
power-up initialization, all interrupt capable devices are initialized and
interrupts enabled. For a few non-normal operational situations (e.g.,
when the car is sitting in a service bay and the technician wants to
reprogram the ECM) we will disable interrupts from selected sources.

Post by Mark Borgerson
In an instrument which is processing analog input and
presenting data to the user, the foreground program accepts
a command, Sets up the ADC to collect the data in an ISR. While
the data is being collected the foreground routine monitors
the user input (for a 'cancel' command, etc.), checks the
status and keeps the user informed on the progress of the
data collection. When collection is finished, the foreground
routine disables the ADC and its interrupt, pulls the data
from the buffer that was filled by he ISR, and presents
it to the user.

We do disable interrupts at various levels using the interrupt mask of
the 68K, but never specific devices in normal operation. The disabling
has to be done for very short periods of time. We can't afford to miss an
interrupt--an engine wants attention no matter what the code is doing.
One of our constant tasks has been to keep an eye on our customers code to
ensure they do not disable interrupts for too long.


~Dave~

[Ian Bell]

Post by David T. Ashley
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.

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

[Dan N]

Post by David T. Ashley
There are ISRs (interrupt service routines), and software that is not part
of an ISR.
One of those is foreground, and one is background.

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