Does anyone need a headache tablet? I seem to have an "unallocated" one now
that JC has reminded me to _DINT and _EINT around the critical sections!
Thanks for that one, JC! :)

Steve, I've found (at least with my JTAG-driven MSPFET with an F149) that
IE1 comes up with 0x82 and this value survives the UART initialization, and
so, when i eint, I *do* get a tx int right away. (So in fact I chose to
clear the flag manually before enabling the ints).

Cheers,

James

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]on Behalf Of
> J.C. Wren
> Sent: quarta-feira, 4 de fevereiro de 2004 21:19
> To: [email protected]
> Subject: Re: [Mspgcc-users] uart
>
>
> This is the code I use for both UARTs in all my MSP430 code
> bases, and
> I've never run into a problem with it.  Are you handling
> yours differently?
>
>     --jc
>
> int putcharx (int data)
> {
>    unsigned char tmphead = (UART0_TxHead + 1) & UART0_TX_BUFFER_MASK;
>
>    while (tmphead == UART0_TxTail)
>       ;
>
>    _DINT ();
>    UART0_TxBuf [UART0_TxHead = tmphead] = data;
>
>    if (!(IE1 & UTXIE0))
>    {
>       IE1 |= UTXIE0;
>       IFG1 |= UTXIFG0;
>    }
>    _EINT ();
>
>    return (data);
> }
>
> interrupt (UART0TX_VECTOR) uart0tx_interrupt (void)
> {
>    int tmptail;
>
>    if (UART0_TxHead != UART0_TxTail)
>       U0TXBUF = UART0_TxBuf [UART0_TxTail = (UART0_TxTail + 1) &
> UART0_TX_BUFFER_MASK];
>    else
>       IE1 &= ~UTXIE0;
> }
> Steve Underwood wrote:
>
> > James Henry Dodd wrote:
> >
> >> Hi Robert,
> >>
> >> If things aren't working, are you sure you followed the UART setup
> >> sequence
> >> properly?
> >> Quoting slau049c.pdf from Texas:
> >> "...
> >> The required USART initialization/re-configuration process is:
> >> 1) Set SWRST (BIS.B #SWRST,&UxCTL)
> >> 2) Initialize all USART registers with SWRST = 1 (including UxCTL)
> >> 3) Enable USART module via the MEx SFRs (URXEx and/or UTXEx)
> >> 4) Clear SWRST via software (BIC.B #SWRST,&UxCTL)
> >> 5) Enable interrupts (optional) via the IEx SFRs (URXIEx
> and/or UTXIEx)
> >> Failure to follow this process may result in unpredictable USART
> >> behavior.
> >> ..."
> >>
> >> IMHO, the behaviour isn't unpredictable: it's sure not to work! :)
> >>
> >> Cheers,
> >>
> >> James
> >>
> >>
> > It is somewhat unpredictable, but you are right - it doesn't work
> > correctly. However, even following this procedure I have
> encountered
> > something odd. When you initially enable the transmit interrupt you
> > would expect am immediate tx empty interrupt (unless you had just
> > stuffed a value into TXBUF). That is what happens with most UARTS.
> > However, I have found I need to write a value into TXBUF to
> kick the
> > interrupt mechanism into life. After that, the tx empty interrupts
> > occur as expected.
> >
> > Regards,
> > Steve
> >
> >
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Mspgcc-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>


Reply via email to