Lpc2000

I'd like to point out that apparently (correct me if I'm wrong!) Jaya 
is radically against system that tolerate any interrupts whose source 
is unidentifiable. Apparently his products must pass some 
certification process that rejects this situation. Brendan's proposal 
is a solution to the problem "how to get a system running using UART 
interrupts", and what Jaya is proposing is a solution to the 
problem "how to get a system running so you never get an interrupt 
whose source you can't identify". It is clear that Brendan doesn't 
think that interrupts from unidentifiable sources are not that much 
of a problem. Hence the misunderstanding (unless I just added a new 
degree of misunderstanding; if that is case, my apologies).

Guille

--- In lpc2000@yahoogroups.com, "brendanmurphy37" 
<brendan.murphy@...> wrote:
>
> 
> Jaya,
> 
> I think there's a bit of a misunderstanding here. I wasn't claiming 
> that your solution for UART interrupts didn't work. Also, I'm aware 
> of how to write UART drivers that don't use interrupts. I have the 
> good fortune to be part of a team of excellent engineers who can 
> assist if required: no help needed thanks!
> 
> My point was that if there's an issue with some feature (in this 
case 
> UART receive interrupts), it's no real solution just to say "don't 
> use the feature". This isn't to say that you can't get a working 
> system that doesn't use the feature. Sorry if this wasn't totally 
> clear.
> 
> The fact is that most people will already have some form of 
interrupt-
> driven UART driver to hand when they come to the LPC2000 series, 
> particularly as the UARTs are compatible with industry standard 
> registers etc. Hence my observation about practicality: it's a bit 
> much to ask them to completely rewrite drivers to avoid interrupts, 
> particularly when other solutions to the issue exist that don't 
> require such radical change.
> 
> If you and your clients want to implement any solution you like, 
I've 
> absolutely no problem with it, nor with validating or proving it 
> incorrect. I don't have the time, and I'm really not that 
interested. 
> I'm happy for you. Honestly!
> 
> This is an open forum however, and I presume you'd accept that it's 
> open for anyone to put forward to alternative viewpoints and 
> solutions to issues as they see them? Particularly if those 
solutions 
> are somewhat simpler in both scope and realisation.
> 
> Which brings me to my second point, and again, I'm assuming there's 
> some sort of misunderstanding involved.
> 
> Some time ago, I posted my own observations and proposed solution 
for 
> spurious interrupts. I'm not claiming authorship of the solution by 
> the way: all I was doing was trying to summarise information 
> available elsewhere and the key points as I saw them. See: 
> http://groups.yahoo.com/group/lpc2000/message/14342
> This is not the same as app note AN10414, which is what you seem to 
> think I'm proposing (according to your statement below). I even 
> included in the post the entire source code for the solution – all 
> four lines of it. You immediately came back and said that what I 
was 
> proposing wouldn't work. I've been trying ever since to find out 
what 
> exactly is the problem you see with it. Is there some failure mode 
> you can describe where it doesn't work? is there some test you've 
> done that shows it failing? My interest in persisting with this 
> enquiry (and apologies for everyone reading all of this for the 
> repetition involved) is that the solution is in use: if it's likely 
> to fail I'd like to know about it. If there is some flaw, I have no 
> problem in acknowledging it and adopting some other alternative 
> solution (yours or someone else's). 
> 
> I've no interest in changing your or anyone else's mind or playing 
> politics (or trading insults and abuse come to that). I'm not 
looking 
> for advice, free or otherwise. Just in establishing two simple 
points:
> 
> - there are alternative viewpoints and solutions
> 
> - if there's a problem with a solution I'm using, I'd like to know 
> what it is
> 
> That's all really.
> 
> Best wishes
> 
> Brendan
> 
> --- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@> wrote:
> >
> > Dear Brendan,
> > 
> > It looks like you are asking for help, yet put on an air and this 
> makes it 
> > difficult for anyone to help without a sour taste in the 
> > mouth.  Nonetheless I shall try to oblige ...
> > 
> > My solution for the UART DOES work and HAS BEEN ADOPTED by 
clients 
> who will 
> > not tolerate spurious interrupts in their systems.  It depends on 
> what the 
> > are is being used for its its limitation in relation to transient 
> behaviour 
> > of its RDA/CTI interrupt sources.
> > 
> > If you recognise that it has a FIFO in the receive channel, and 
you 
> have 
> > suitable timers operating in your system, you can poll the UART 
> using these 
> > timers.  The most important point to note in any solution (from a 
> spurious 
> > interrupts perspective) is that it should not result in the 
> generation of 
> > spurious interrupts.  Hence I consider the work around given in 
> Philips 
> > AN10414, which I believe is what you are proposing to do, not a 
> solution.
> > 
> > If you allow transient interrupts into your system the problems 
you 
> need to 
> > entertain may not limited to just spurious interrupts of the type 
> that I 
> > demonstrated by way of experiment.  You have to look at the 
design 
> of PL190 
> > itself to understand what else can happen.
> > 
> > Interim information I have suggests that PL192 can handle 
> interrupts that 
> > exhibit transient behaviour by design.  You will note it does not 
> have any 
> > default vector.  So one solution is to wait for the next 
iteration 
> of 
> > silicon and hope Philips will incorporate PL192 -- you have to 
ask 
> Philips.
> > 
> > The other solution is to look for other ARM variants after 
checking 
> if they 
> > incorporate PL190 VIC (it has a default vector) and run the 
> experiments I 
> > have provided on these to see if the same problem manifests on 
> these other 
> > systems.
> > 
> > If you need further comment on your particular work-around, I 
> recommend you 
> > seek professional advice.  This is as far as I am prepared to go 
in 
> > relation to free advice for your particular problem.
> > 
> > Kind regards,
> > 
> > Jaya
> > 
> > >Message: 14
> > >    Date: Wed, 22 Mar 2006 14:57:03 -0000
> > >    From: "brendanmurphy37" <brendan.murphy@>
> > >Subject: Re: spurious interrupts on LPC
> > >
> > >
> > >Jaya,
> > >
> > >I've no interest in politics, nor in proving or disproving what 
you
> > >say.
> > >
> > >The point I was making (repeatedly!) is that your "solution" for 
> UART
> > >related spurious interrupts is in fact no solution, as it simply 
> says
> > >don't use the relevant interrupt. This isn't very practical.
> > >
> > >I've also asked you (again, repeatedly) for information on why 
you
> > >claim having an empty default interrupt handler won't work. I'm 
> very
> > >interested in this, as it's currently in use; if it's likely to 
> fail,
> > >I'd like to know about it.
> > >
> > >Having said that, I would imagine most people are extremely 
tired 
> of
> > >this topic at this stage, so if you don't want to answer, I'm 
sure 
> no
> > >one will mind. I'm certainly happy enough to stop right now.
> > >
> > >Keep up the good work.
> > >
> > >Brendan
> > 
> > Send instant messages to your online friends 
> http://au.messenger.yahoo.com
> >
>