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.> 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.Never heard it used like that.> 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.Nope. I've never heard anybody use it that way in embedded systems.> 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,So the forground was the non-interrupt stuff. That's the usage I've always heard.> the interrupts were still working and keeping the watchdog happy.The ISR stuff was the background.> 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.Yup. That's the usage I've always heard. Perhaps it's regional?> 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. -- Grant Edwards grante Yow! if it GLISTENS, at gobble it!! visi.com
Foreground vs. Background (Nomenclature Question)
Started by ●June 8, 2006
Reply by ●June 9, 20062006-06-09
Reply by ●June 9, 20062006-06-09
"David T. Ashley" <dta@e3ft.com> wrote in message news:UH4ig.7345$cL3.2722@fe12.usenetserver.com...> > 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.> 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
Reply by ●June 9, 20062006-06-09
In article <1149822069.495282.17650@j55g2000cwa.googlegroups.com>, bungalow_steve@yahoo.com says...> > 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? > > > > 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
Reply by ●June 9, 20062006-06-09
Dave 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.True if you a running on a PC but this is comp.arch.embedded and here it means something completely different. Ian
Reply by ●June 9, 20062006-06-09
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? > > 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
Reply by ●June 9, 20062006-06-09
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
Reply by ●June 9, 20062006-06-09
Grant Edwards wrote:> On 2006-06-08, David T. Ashley <dta@e3ft.com> 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. > > OK, we'll take that as read. > >> But, which is which? > > ISRs are background. >Nope, they are foreground.>> What is the right nomenclature? > > ISRs are background. Everything else is foreground. >Nope, everything that runs outside and interrupt is background.>> What is the definitive reference for the right nomenclature? > > This posting. >Nope, this correction ;-) Ian
Reply by ●June 9, 20062006-06-09
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.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 by ●June 9, 20062006-06-09
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. ;-) 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 by ●June 9, 20062006-06-09
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. 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~
