"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote in message news:vqOdnUuVfIZrDRHZRVnyuw@pipex.net...> "steve" <bungalow_steve@yahoo.com> wrote in message > 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
Foreground vs. Background (Nomenclature Question)
Started by ●June 8, 2006
Reply by ●June 11, 20062006-06-11
Reply by ●June 11, 20062006-06-11
Dave wrote:> 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?No, but is needs to be done with great care.> 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
Reply by ●June 11, 20062006-06-11
Steve at fivetrees wrote:> "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. >I am aware of that. However, in critical systems it is preferable not to do so as it makes the system less deterministic.> 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
Reply by ●June 11, 20062006-06-11
Steve at fivetrees wrote:> 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.
Reply by ●June 11, 20062006-06-11
On Sun, 11 Jun 2006 22:57:12 +0100, Steve at fivetrees wrote:> 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~
Reply by ●June 11, 20062006-06-11
"Dave" <dave@comteck.com> wrote in message news:pan.2006.06.11.23.40.09.681871@comteck.com...> On Sun, 11 Jun 2006 22:57:12 +0100, Steve at fivetrees wrote: > >> 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
Reply by ●June 11, 20062006-06-11
"Ian Bell" <ruffrecords@yahoo.co.uk> wrote in message news:448c99ed.0@entanet...> Steve at fivetrees wrote: > >> "steve" <bungalow_steve@yahoo.com> wrote in message >> news:1150055826.513673.196410@i40g2000cwc.googlegroups.com... > >> 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" <bungalow_steve@yahoo.com>, as indicated by the accreditisationificationage. Steve http://www.fivetrees.com
Reply by ●June 12, 20062006-06-12
Dave wrote:> > 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
