Foreground vs. Background (Nomenclature Question)

Dave wrote:

> On Fri, 09 Jun 2006 13:02:41 +0100, Ian Bell wrote:
> 
>> 
>> 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

Ian Bell wrote:
> Dave wrote:
> 
... snip ...
> 
> Depends on your definition of embedded and PC. We used to build
> PCs into robot systems but I would not call that embedded.
> 
>> 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>

-- 
 "Our enemies are innovative and resourceful, and so are we. 
  They never stop thinking about new ways to harm our country
  and our people, and neither do we."          -- G. W. Bush.
 "The people can always be brought to the bidding of the
  leaders.  All you have to do is tell them they are being
  attacked and denounce the pacifists for lack of patriotism
  and exposing the country to danger. It works the same way
  in any country."                         --Hermann Goering.

On Thu, 08 Jun 2006 21:38:02 -0000, Grant Edwards <grante@visi.com>
wrote:

>On 2006-06-08, Dave <dave@comteck.com> wrote:
>> On Thu, 08 Jun 2006 17:11:43 -0400, David T. Ashley wrote:
>>
>>> 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. 
>
>> 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

Anton Erasmus wrote:

> On Thu, 08 Jun 2006 21:38:02 -0000, Grant Edwards <grante@visi.com>
> wrote:
> 
>>On 2006-06-08, Dave <dave@comteck.com> wrote:
>>> On Thu, 08 Jun 2006 17:11:43 -0400, David T. Ashley wrote:
>>>
>>>> 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.
>>
>>> 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

"Ian Bell" <ruffrecords@yahoo.co.uk> wrote in message 
news:448c5473.0@entanet...
>
> 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 

Steve at fivetrees wrote:

> "Ian Bell" <ruffrecords@yahoo.co.uk> wrote in message
> news:448c5473.0@entanet...
>>
>> 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.

> 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

Steve at fivetrees wrote:

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

steve wrote:

> 
> Steve at fivetrees wrote:
> 
>> 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

On Sun, 11 Jun 2006 20:26:18 +0100, Ian Bell wrote:

> Steve at fivetrees wrote:
> 
>> 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~

"steve" <bungalow_steve@yahoo.com> wrote in message 
news:1150055826.513673.196410@i40g2000cwc.googlegroups.com...
>
> Steve at fivetrees wrote:
>
>> 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