jayasooriah wrote:
>
> --- In lpc2000@yahoogroups .com ,
> Tom Walsh wrote:
> > ========= begin IRQ ===========> > __irq:
> > stmfd sp!,{lr} // save return address.
> > mrs lr,spsr // save status reg.
> > stmfd sp!,{r4-r5,lr} // save work regs and status reg.
> > ldr r4,=VICVectAddr // get ISR address from vic.
> > ldr r5,[r4]
> > msr cpsr_c,#MODE_ SVC // Supervisor Mode and re-enable
> > interrupts.
> > stmfd sp!,{r0-r3,r12, lr} // save work registers and
> return on
> > stack.
> > mov lr,pc // set return to common exit of ISR.
> > mov pc,r5 // execute the proper ISR handler.
> > ldmfd sp!,{r0-r3,r12, lr} // restore work regs and return.
> > msr cpsr_c,#MODE_ IRQ|I_BIT // switch back to IRQ mode,
> > interrupt off.
> > ldr r4,=VICVectAddr // ack the interrupt.
> > mov r5,#0xff
> > str r5,[r4] // touch VIC to update priorities.
> > ldmfd sp!,{r4-r5,lr} // restore work regs and IRQ return.
> > msr spsr_cxsf,lr // restore spsr of irq mode.
> > ldmfd sp!,{lr} // restore return address.
> > subs pc,lr,#0x4 // do the return from IRQ interrupt.
> > ======== snip ============ ====>
> For the benefit of those who are looking at abstracting a general
> purpose re-entrant IRQ handler from the above solution, I like to
> point out that the above solution assumes FIQ is always enabled on
> entry into IRQ handler.
>

Heh, I forgot to mention, the FIQ exception is not used in my system.
That is a good point though, I should be careful of that and setup some
vector in the external RAM so that a future runtime app could use the FIQ...

TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread

--- In l..., "Brendan Murphy"
wrote:
>
> --- In l..., "jayasooriah" wrote:
> > If it is true that one "loses the benefits of FIQ" by disabling FIQ,
> > then the same should apply to disabling IRQ. Clearly it is not
> true.
>
> I rather think you've missed the point. If you need to have an
> interrupt that needs on occasion to be disabled, just define it as an
> IRQ.
>
> > Off the cuff, one example is when FIQ is used in a manner similar to
> > DMA, but for peripherals that do not support DMA. You *must*
> suspend
> > this "DMA" handled by FIQ handler when you fiddle with the buffers.
>
> To use your example, I'd simply use the highest priority IRQ to
> handle the DMA and enable and disable it as required.
>
> >
> > There are many examples of this kind of use. The FIQ and IRQ bits
> are
> > independent in the PSR precisely for this purpose.
>
> FIQs are primarily needed to support very high priority interrupts
> that are handled imediately. If you ever disable them, the latency of
> the handler is unknown, which as I said obviates one of the main
> reasons for using them (predictable worst case performance).
>
> I see no reason to use an FIQ when a high-priority IRQ can be used in
> its place.
>

Every time someone does not agree with you, you accuse them of missing
the point. This is why I dont like to respond to your posts.

There is little point in you repeating yourself. Those of use who
understand DMA appreciate that this function on is better served by
FIQ than IRQ because of the alternate register bank that can hold
buffer pointers and transfer counts.

Jaya Start a New Thread

--- In l..., "jayasooriah" wrote:

> Every time someone does not agree with you, you accuse them of missing
> the point. This is why I dont like to respond to your posts.
>

Apologies, your statement:

FIQ, then the same should apply to disabling IRQ /END QUOTE>

had led me to believe you didn't understand the point I was making, as
it makes little sense in the context of that point.

> There is little point in you repeating yourself. Those of use who
> understand DMA appreciate that this function on is better served by
> FIQ than IRQ because of the alternate register bank that can hold
> buffer pointers and transfer counts.
>

A good point, in that FIQ have other advantages over IRQs other than
deterministic worst-case response times.

Again, personally I'd either code the DMA FIQ so that it would work
correctly without being disabled, or relegate it to a high-priority IRQ
and forgo the use of the banked registers, which have fairly minimal
time savings in any case.

By the way, I had thought I'd made it clear that I'm not asking you or
anyone else to agree with me; all I was doing was pointing out there
was an alternative approach.

We've both made our points, so unless you have some other relevant
technical issue to raise, I suggest we end this.

Brendan Start a New Thread

Hi Richard,

What a can of worms :) I like that little solution. I can't see it
saving many instructions but I suppose if you see the need to do it,
an extra instruction or three makes a difference! I'm happy playing
around with 8051 assembler, but the times I've looked through ARM
assembler I'm just stunned with the number of ways each instruction
can be used.

As this product is so simple, I think I'll just stay with the remapped
vectors in SRAM... but I'm also going to need to make a different
boot monitor for a product at work so I'll definitely save this
discussion for later reference.

Thanks for the help!
Darcy
--- In l..., Richard Duits wrote:
>
> Hi Darcy,
>
> Looks like a lot of LPC users have given this a lot of thought. I kept
> things a lot simpler than the other replies I read.
>
> For the Software Interrupt vector (SWI instruction) I use a fixed
> address in the application sectors.
>
> The IRQ address is loaded directly from the VIC.
>
> For the FIQ the "MOV PC, R12" is used. Before using the FIQ you can
call
> a assembly function to set the R12 in the FIQ register bank. R12
will be
> preserved by an IRQ function implemented in C or an assembly function
> can leave another address in R12 depending on the state of the hardware
> at the end of the interrupt. I used this for a high priority ADC
> interrupt to remember wich ADC channel was selected. This saved me a
> "switch (adc_channel) { .... }" like construct at the start of the FIQ.
>
> The other exceptions are handled by the custom boot loader. They
usually
> just reset the device, but they can be used to dump the registers to a
> serial port.
>
> This way it is usually not needed to remap the vectors to SRAM.
>
> Regards,
> Richard.
> Start a New Thread

> FIQs are primarily needed to support very high priority interrupts
> that are handled imediately. If you ever disable them, the latency of
> the handler is unknown, which as I said obviates one of the main
> reasons for using them (predictable worst case performance).

only if you disable them *at a time when they are needed*. DMA (to use
the canonical example) is not needed while it is being set up.

> I see no reason to use an FIQ when a high-priority IRQ can be
> used in its place.

You are right of course, but note the word "can". For very special
purposes (which is what FIQ is for) you can't use an IRQ because you
need the banked registers.

Wouter van Ooijen

-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu Start a New Thread