Lpc2000

At 12:48 PM 2/22/04 -0500, you wrote:
> > In light of the previous revelations, I tried what I described before.
> > Does anyone know what is going on here ?
> >
> > Outputting a character into circular buffer works fine like this :
> > =======================================
> > UINT temp;
> >
> > /* Handle TX buffer wrap */
>temp = (tx_head+1)%RS232_SIZE;
> >
> > /* Disable TX interrupts */
> > U0IER = 0x01;
> >
> > /* Circ buffer not empty ? */
> > if (comm_tx_running)
> >     {
> >     comm_tx[tx_head] = (UCHAR)ch;
> >     tx_head = temp;
> >     }
> > else
> >     {
> >     comm_tx_running = 1;
> >     U0THR = ch;
> >     }
> >
> > /* Reenable TX interrupts */
> > U0IER = 0x03;
> > return (ch);
> >
> >
> > But doing a write to the TX buffer with post increment also causes Default
> > IRQs :
> > ====================================================
> >
> > /* Disable TX interrupts */
> > U0IER = 0x01;
> >
> > /* Circ buffer not empty ? */
> > if (comm_tx_running)
> >     {
> >     comm_tx[tx_head++] = (UCHAR)ch;
> >     tx_head %= RS232_SIZE;
> >     }
> > else
> >     {
> >     comm_tx_running = 1;
> >     U0THR = ch;
> >     }
> >
> > /* Reenable TX interrupts */
> > U0IER = 0x03;
> > return (ch);
> >
> > -------------------------------------------------------
> >
> > Could this have to do with optimisation ?
> > I have to honestly volunteer I'm stumped with that one.
> >
> > -- Kris
>
>I'd second this.  I see nothing in here to stop a compiler from
>moving stuff around to it's hearts content.  You might want
>to look at adding some barrier() statements to the above code
>to prevent that kind of code rearrangement.

GCC is more prone to this than other compilers I've worked with.  Most of 
them seem to take the approach of "no re-ordering unless provably 
beneficial" whereas GNU's appears to be "reorder as long as it's not 
wrong".  A different emphasis that makes stepping through optimized code a 
little more interesting.

Judicious use of volatile helps.  Re-doing critical sections in assembly 
certainly works.

If it's an ordering problem I suspect that if both U0IER and 
comm_tx_running are volatile you shouldn't have a problem since the 
compiler is not allowed to optimize the order of reference to volatile 
variables..

A quick google search ( barrier GNU reordering) reveals this item

http://compilers.iecc.com/comparch/article/03-03-158

I think I'd go for full assembly for control rather than inline asm.

Hmm, actually a point.  If you want to check that optimization is messing 
with your execution order just dump it and read it.  Always an illuminating 
process :)

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III