Lpc2000

Richard,

I know I said I wouldn't post anything else on this topic, but 
please bear with me on the following: I hope you'll understand why.

From your statement "I have run FreeRTOS apps with heavy interrupt 
overhead for days with a default handler that does nothing but jump 
to itself", am I correct in assuming that the handler you refer to 
just loops to itself?

If I am correct in this assumption, you should really look at doing 
something else. 

Just because you haven't seen the behaviour, doesn't mean it doesn't 
exist. We first encountered it, before it was documented, by running 
a very severe stress test. After something of the order of few 
hundred million interrupts handled perfectly, the default interrupt 
handler was called, and the system failed.

It is this very sporadic nature of the problem that makes it so 
invidious.

So as not to re-invoke controversy, I won't promote one solution 
over another. I believe both those described recently are valid 
approaches: there are probably other solutions too.

If I'm incorrect in my interpretation of what you wrote, I hope you 
won't mind me making this point in any case.

Brendan


--- In lpc2000@yahoogroups.com, nospam@... wrote:
>
> >Given the assertion that Brendon's solution/
> >approach/workaround meets my needs - Are 
> >there any LPC RTOSes out there that already 
> >handle this problem similarly or are amenable 
> >to this solution given that device drivers are 
> >crafted accordingly?  I'm thinking about FreeRTOS 
> >specifically, but I'd like to know if this has been 
> >considered a significant reliability factor for 
> >LPC RTOSes - from the perspective of the 
> >practical (as opposed to academic) community.
> 
> Sorry I cannot give a specific answer as I stopped following this 
thread 
> some days (weeks?) ago so did not read the post to which you 
refer.  
> However, with regard to FreeRTOS I'm not aware that the code need 
do 
> anything, and therefore why this is such a big subject. 
> 
> I tend to use startup code as supplied by the compiler or silicon 
> manufacture.  This sometimes does and sometimes does not add a 
default 
> handler.  Such a handler does nothing anyway other than return 
(this is my 
> understanding of the situation without having trawled through all 
the posts 
> which may suggest otherwise).  This is easy for an application 
writer to 
> include, and presumably will be checked by anybody deploying a 
real 
> application. 
> 
> I have run FreeRTOS apps with heavy interrupt overhead for days 
with a 
> default handler that does nothing but jump to itself, and I have 
never seen 
> it get called.  Also I cannot think of any time in my career when 
I have 
> ever needed to check whether a function was called synchronously 
or by an 
> interrupt by checking the I bit of the status register. 
> 
> In summary, FreeRTOS does nothing special with default handlers 
and cannot 
> therefore be considered as 'designed' with this in mind. 
> 
> Regards,
> Richard.
>