Lpc2000

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