Lpc2000

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
>