Foreground vs. Background (Nomenclature Question)

Dave wrote:

> On Fri, 09 Jun 2006 07:55:45 +0100, Ian Bell wrote:
> 
>> Dave 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.
>> 
>> 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.

> 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
> 
> 
>     ~Dave~

Dave wrote:
>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.

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~

On 2006-06-09, Andy Sinclair <me@privacy.net> wrote:
> Dave wrote:
>>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.

-- 
Grant Edwards                   grante             Yow!  The PINK SOCKS were
                                  at               ORIGINALLY from 1952!! But
                               visi.com            they went to MARS around
                                                   1953!!

"Ian Bell" <ruffrecords@yahoo.co.uk> wrote in message 
news:44891edd.0@entanet...
> Grant Edwards wrote:
>
>> On 2006-06-09, Dave <dave@comteck.com> wrote:
>>
>>>> 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.

"Grant Edwards" <grante@visi.com> wrote in message 
news:128iupghotkni7c@corp.supernews.com...
> On 2006-06-09, Andy Sinclair <me@privacy.net> wrote:
>> Dave wrote:
>>>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 

Grant Edwards wrote:
>Andy Sinclair wrote:
>> 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.

In article <pan.2006.06.09.10.05.35.216700@comteck.com>, 
dave@comteck.com says...
> On Thu, 08 Jun 2006 21:33:53 -0700, Mark Borgerson wrote:
> 
> > 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.
> 
> 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.
> 
> 
>     ~Dave~
> 

Mark Borgerson

On Fri, 09 Jun 2006 09:39:43 -0700, Mark Borgerson wrote:

> In article <pan.2006.06.09.10.05.35.216700@comteck.com>, 
> dave@comteck.com says...
>> 
>> 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.

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

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~

Grant Edwards wrote:

> On 2006-06-09, Andy Sinclair <me@privacy.net> wrote:
>> Dave wrote:
>>>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