Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: spurious interrupts on LPC

2006-03-24 by ian.scanlon

Brendan,

I think it is only fair to let Jayasooriah save face on this one, 
maybe let it go.

Ian Scanlon


--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Dear Brendan,
> 
> I am amazed that you would believe I have not answered your 
question on six 
> separate occasions and yet repeat the very same question again.
> 
> You must have been getting something or you will not be asking the 
same 
> question over and over again so many times.
> 
> Let me try another angle.
> 
> Try explaining what "The VIC does not handle interrupts that 
exhibit 
> transient behaviour" (direct quote from PL190 TRM) means.
> 
> The TRM does say is that when an interrupt exhibits transient 
behaviour, 
> "the priority logic of VIC is not set".  What does "not set" means?
> 
> Set to 0?  1?  ... 15? 16?
> 
> Is the state of the priority logic defined after such an event?
> 
> Who defines the behaviour of the VIC when it is subject to 
interrupts that 
> exhibit transient behaviour?
> 
> Can I define it based on the result of my experiments?  Can you?
> 
> I am happy to rephrase what I said thus: "I am not able to define 
what 
> happens in your system when you do the things you said you are 
doing" if 
> this will put an end to this saga.
> 
> One more thing.  My questions above are for you to silently answer 
in your 
> own mind, in a hope that this would help you understand.  It is not 
my 
> intention for you to respond to my post and answer these questions.
> 
> A very tired-of-Brendan Jaya
> 
> --- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@> 
wrote:
>  >
>  >
>  > Jaya,
>  >
>  > I give up! I've now asked you on seven separate occasions for
>  > evidence to back your very specific claim that the solution I 
choose
>  > to take will not work. I'm forced to the conclusion that one of 
the
>  > following alternatives is true:
>  >
>  > - you have some evidence, but are unwilling to share it (but 
why?)
>  >
>  > - you don't believe you need evidence to back a claim (which is 
an
>  > odd position for an academic to take)
>  >
>  > - you have no evidence (this is now my working assumption)
>  >
>  > You characterise the solution I'm using as applying some kind of
>  > catch-all fix to hide behaviour that is unpredictable or poorly
>  > understood. I don't know of any professional engineer who works 
on
>  > this basis: I certainly would not pass for release any product 
that
>  > used arbitrary solutions to fix behaviour that wasn't fully
>  > characterised.
>  >
>  > Your latest claim is that "Â…the behaviour of your system under 
these
>  > conditions is UNDEFINED". Based on all the available evidence, 
this
>  > is simply not true. Philips and ARM have between them have 
documented
>  > exactly what happens in exactly what circumstances.  ARM do not 
state
>  > that the VIC's behaviour is undefined. The system is not
>  > unpredictable or indeterminate: it always behaves the same way in
>  > response to the same inputs. Indeed, your own experiments have
>  > confirmed this documented behaviour. It calles the default 
interrupt
>  > handler in response to very specific events, which both Philips 
and
>  > you have documented.
>  >
>  > With knowledge and understanding of this known, deterministic,
>  > behaviour a very simple work-around can be provided to avoid
>  > undesirable consequences of that behaviour. All the evidence
>  > (including your own!) is that such a solution is completely
>  > predictable, deterministic and fully characterised.
>  >
>  > Of course, both you and I know that I can't prove this last
>  > statement: there could be some set of inputs that make the system
>  > behave in some unpredicted or undefined way. It's very easy to 
prove
>  > the opposite though: all you have to do is provide some evidence 
of
>  > it failing to work as predicted. Unfortunately, you don't seem to
>  > have any such evidence. My conclusion is that until you or 
someone
>  > else can provide any, the solution I'm using is sound.
>  >
>  > I've no intension of asking you an eighth time to back your 
claim:
>  > I'm tired and have had enough.
>  >
>  > Best wishes,
>  >
>  > Brendan
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.