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

"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

"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 

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~

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.

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

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

"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

"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 

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~