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
Show quoted textHide quoted text
> therefore be considered as 'designed' with this in mind.
>
> Regards,
> Richard.
>