Honored Contributor
Honored Contributor
if you use the isr/dsr setup you can do it that way, and there's no problem. but if you have a fast lowlevel interrupt you cannot aford waiting for the dsr to reenable the irq.
i do not claim that the approach is an error just that each irq eats 80 bytes of stack and that you'll have to allow for this mem usage in each stack in every thread.
if you have interrupts comming back to back, which is quite normal, the stackpointer will not be restored between each of them and eventually you'll crash.
<div align='right'><{post_snapback}> (index.php?act=findpost&pid=11370)
--- quote end ---
--- Quote End --- jskjoet, I see your point, but it seems that eCos has this worked out by means of the (configurable) separate interrupt stack. I found this a good read, in case you haven't already seen it: http://ecos.sourceware.org/docs-1.3.1/ref/ecos-ref.c.html (http://ecos.sourceware.org/docs-1.3.1/ref/ecos-ref.c.html) It also seems to me that if this is a genuine problem it may be time to take another look at the system: Is the ISR (not DSR) code taking too long to execute? Can anything be done to slow the rate of interrupts? At some point the processor will be choked no matter what; I think that eCos is trying to be clever here with the separate isr/dsr architecture specifically to allow you to make your ISR code as brief as possible. Thats just my interpretation though. One big caveat: I'm just getting into eCos now (here at Altera) and haven't yet done what I'd consider a complex design with it yet.
