Lpc2000

I am planning to do the same. It is really sad that
this forum occasionally generates SPAM. 

Balaji

--- "George M. Gallant, Jr." <ggallant571@...>
wrote:

> Jayasooriah,
> 
> Congratulations. You are the first person I have
> ever created a filter
> to automatically route
> all email from directly to the trash bin! I won't
> even get your
> everlasting nonsensical replies!!!!
> 
> George
> 
> On Sun, 2006-03-26 at 00:03 +1100, Jayasooriah
> wrote:
> 
> > Hello,
> > 
> > For what it is worth, here is a summary of the
> issues surrounding the
> > very 
> > first question I raised relating to spurious
> interrupts on LPC 2000
> > family.
> > 
> > A different perspective emerges you look at the
> distractions by way
> > of 
> > noise generated those whom I have labelled "the
> usual suspects".
> > 
> > 
> > ==> 2006-03-14 21:40:10 GMT Jayasooriah
> > 
> > I looked at LPC200 FAQ claim that spurious
> interrupts can occur in any
> > ARM7 
> > that incorporates the VIC.  I was surprised and I
> asked Robert
> > (Philips) to 
> > clarify:
> > 
> > 1/  Is the spurious interrupt problem specific to
> implementation of
> > VIC on 
> > LPC, or is it a generic VIC problem?
> > 
> > 2/  Do any other ARM cores with VIC suffer from
> the same problem?
> > 
> > [Has anyone answered this question?  No?  Yes ...
> no!]
> > 
> > ==> 2006-03-15 00:12:07 GMT Robert (Philips)
> > 
> > Forwarded my question the author of the FAQ.
> > 
> > [Neither Robert nor Philips has provided any
> response from the author
> > to date.]
> > 
> > Asks me to investigate this on other ARM variants
> and report my
> > findings.
> > 
> > 2006-03-15 07:06:37 GMT Jayasooriah
> > 
> > I respond by saying that none of the other
> variants make this claim.
> > 
> > I reiterate that I am looking for references to
> substantiate the claim
> > in 
> > Philips LPC200 FAQ and Applicaition Note 10414
> that all ARM7 variants
> > with 
> > VIC suffer from spurious interrupts that LPC
> suffers from.
> > 
> > [To date, there has been no reference from
> Philips, Robert or anyone
> > else 
> > for that matter to substantiate this claim.]
> > 
> > I did lookup references to spurious interrupts in
> relation to ARM7 and
> > most 
> > of them come back to LPC2000.  There was even a
> reference to LPC2000
> > in 
> > relation to spurious on lecture notes in a
> University course!  It does
> > look 
> > like the LPC family is very well known for its
> spurious interrupts
> > like no 
> > other processor.
> > 
> > I will admit I found few references relating to
> peripheral on
> > particular 
> > ARM variants, but these appear to be peripheral
> specific -- there has
> > been 
> > no other claim I can find that attributes the
> issue as generic to any
> > ARM7 
> > + VIC.
> > 
> > We did not get an answer to the question, but we
> did have a very
> > active 
> > thread with lots of distractions from the usual
> suspects:
> > 
> > Distraction #1:  ARM FAQ 3677 explains spurious
> interrupts in ARM7.
> > 
> > At first there was rejoicing amongst the usual
> suspects at how quickly
> > my 
> > question was dealt given it looked I was challenge
> the legitimacy of
> > a 
> > claim by Philips.
> > 
> > When we got to the bottom of this and learnt of
> the subtle difference 
> > between spurious and surprise interrupts, and that
> this FAQ discusses 
> > surprise interrupts, not spurious interrupts, the
> usual suspects went
> > quiet 
> > for a while ...
> > 
> > Then someone who claimed to have many years
> experience in this field
> > made a 
> > bungle and claimed that my solution does not allow
> nested interrupts.
> > 
> > Distraction #2:  My solution is not acceptable
> because it does not
> > allow 
> > nested interrupts.
> > 
> > There was another round of rejoicing from the
> usual suspects, that my 
> > solution is not accepted to anyone in the real
> world.
> > 
> > I pointed out the bungle.   Things went quiet for
> while.
> > 
> > There was this one person who persisted on having
> his implementation 
> > validated by by me through this forum.  This led
> to a further
> > incorrect 
> > claim relating to my solution.
> > 
> > Distraction #3:  My solution in relation to UARTs
> is not a solution
> > because 
> > one cannot use the UART if one do not enable
> receiver interrupts.
> > 
> > I pointed out that how one uses timer interrupts
> to receive characters
> > as 
> > the UARTs have a FIFO in the receive channel, and
> that this method has
> > been 
> > put to practice and shown to work.
> > 
> > The same persistent person then picks up another
> issue in relation to 
> > validating his solution, regarding my statement
> that what happens in
> > the 
> > case of what this person was doing is undefined.
> > 
> > Distraction #4:  Prove the VIC behaviour is
> "UNDEFINED" if one polls 
> > interrupt sources one by one in the "spurious
> interrupt handler".
> > 
> > I point out that I cannot define the behaviour
> because the PL190 TRM 
> > clearly states this something it was not designed
> to handle, and that
> > if 
> > such an event did occur, its priority logic cannot
> cope with it.
> > 
> > I did say that came to this view having discussed
> the matter with ARM,
> > and 
> > having read responses from engineer in ARM working
> on PL192 design.
> > 
> > [PL192 is the successor to PL190 and it can handle
> interrupts RDA/CTI
> 
=== message truncated ===

Dream is just a dream.  A goal is a dream with a plan and a deadline.
- Harvey Mackay