Jumping in here, but couldn't locate the previous message(s), so I don't
know about the origin of the discussion. Did the subject change?

And why is this OT?

David Cary wrote:

> It would be nice if, after a "return-from-interrupt-and-enable-interrupts",
> at least one instruction were executed before the CPU was interrupted
> again. Then we could guarantee at least some progress. Are there *any*
> CPUs that do this? 

Not that I know of, for a reason.


> With the few CPUs I know, the "main loop" background task completely
> starves, not making any progress, if interrupts come in too fast. 

That's a faulty design, in a way similar to an oscillating amplifier. Just
shouldn't happen...

The reasons interrupts react fast and repeatedly so is because that's what
people (often) use them for :)  If you don't need it that fast, poll the
event in the main loop. This makes sure that this event never starves the
rest of the process.

You need to make sure that you can handle the worst-case, absolute maximum
interrupt frequency, much in the same way you need to make sure you can
handle the worst-case, absolute maximum temperature and other such outside
factors. There's no safety net, unless you build one in.

There are many applications where it wouldn't do much good even if the
background activity could somehow go on a few instructions at a time. If it
isn't working as designed, all bets are off WRT the result, and you can't
predict what happens (after all, you did /not/ analyse and design for this
situation). So you need to design for it -- and that's just as possible
without this feature as it would be with it. That's probably the reason why
no CPU has this feature.


> Perhaps it would be good to think of the little chunk of code
> if_interrupt_A_comes_in_too_fast_then_disable_A() as a function. 

There is: if you don't need it fast but it may come fast, poll it. Of
course you may (or will) miss events in such a case. Whether that's a
problem depends on the application. 

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist