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.
Foreground vs. Background (Nomenclature Question)
Started by ●June 8, 2006
Reply by ●June 8, 20062006-06-08
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.> What is the right nomenclature?ISRs are background. Everything else is foreground.> What is the definitive reference for the right nomenclature?This posting. -- Grant Edwards grante Yow! Are BOTH T.V.S on?? at visi.com
Reply by ●June 8, 20062006-06-08
"Dave" <dave@comteck.com> wrote in message news:pan.2006.06.08.22.32.08.953618@comteck.com...> 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. 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
Reply by ●June 8, 20062006-06-08
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. -- Grant Edwards grante Yow! I need "RONDO". at visi.com
Reply by ●June 8, 20062006-06-08
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. But, again, it has nothing to do with ISRs/not ISRs. ~Dave~
Reply by ●June 8, 20062006-06-08
Grant Edwards 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.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.
Reply by ●June 8, 20062006-06-08
"Dave" <dave@comteck.com> wrote in message news:pan.2006.06.09.00.42.50.310622@comteck.com...> 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):Many embedded systems (and almost all of mine) are OS-less.> 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.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.> 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
Reply by ●June 8, 20062006-06-08
On Thu, 08 Jun 2006 22:38:50 +0100, Steve at fivetrees wrote:> "Dave" <dave@comteck.com> wrote in message > news:pan.2006.06.08.22.32.08.953618@comteck.com... >> >> 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~
Reply by ●June 8, 20062006-06-08
"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote in message news:mbqdnXus4OjwJhXZRVnyqQ@pipex.net...> 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. > >> 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.
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.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.