Robert Adsett wrote:
> At 02:22 PM 2/22/04 -0500, you wrote:
> >At 10:13 AM 2/22/04 -0600, you wrote:
> > >As a side note. The disabling and restoring of the global interrupt
> > >flag in the cpsr can has a similar problem.
> >
> ><snip>
> >
> > >For more info on this, Atmel has
> > >an APP note discribing it on their web site in the AT91 ARM7 section.
> >
> >Thanks for the pointer.
>
> I just had a chance to read the app note (I presume this is the one
> http://www.atmel.com/dyn/resources/prod_documents/DOC1156.PDF)
> <http://www.atmel.com/dyn/resources/prod_documents/DOC1156.PDF%29> and it
> appears to be warning about faults that can happen when using a style of
> code I would consider very error prone to begin with. Unless I'm missing
> something (I've only had a little while to consider it) the only time a
> problem occurs if an interrupt routine actually modifies the cpu
> status of
> the interrupted code. What would ever prompt anyone to do that in the
> first place?
>
> [snip]
It's a common method of creating interrupt prioritization. If you
have a "slow" interrupt routine, or something more critical, it's common
to re-enable interrupts inside the interrupt routines.
As an example, the AVRs (and I'm still laying out my board, after a
brief haitus, so I haven't gone back to look at the interrupt internals
on the LPC), if you have a timer routine that takes 500 or 1000us to
complete, and you're getting high speed serial interrupts, you may
choose to re-enable interrupts in the timer routine so that the serial
routine can be serviced.
However, some interrupts this can't be done for, such as... serial
interrupts. Because until you read the data register, the interrupt
will remain pending, and if you re-enable interrupts, you'll interrupt
right back into the serial interrupt handler. And you can't effectively
pre-calculate the buffer pointer, so you really have to just about
perform the complete interrupt routine.
I kinda miss the days of the 8051 and such when an arbitrary
peripherial that generates interrupts could be specified to be high or
low priority.
--jcMessage
Re: [lpc2000] UART TX FIFO and INTs problem - SOLVED
2004-02-22 by J.C. Wren
Attachments
- No local attachments were found for this message.