Lpc2000

>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\ufffdm 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.