soltras wrote:
Thanks JC!
However I hardly understand your code:
1. Your putcharx(...) have int data in the argument. Is it char* or char?
Since the UART queue and UDR are bytes, the top 8 bits are ignored in
characters sent to the routine. int's are returned so that a routine
like this could return a status code. If you return a char, you have no
way of distinguishing 0xff from -1 to indicate a buffer full condition,
UART disabled, or whatever you choose. It's also traditional. You'll
find that putchar() on just about every C implementation ranging from a
8051 to a DEC Alpha returns int. So int it is.
2. Is DINT() necessary ? Is not enough IE1 &= ~UTXIE0
I suppose if you wanted to, it'd probably work. While this particular
implementation's variables aren't affected by other routines, I have had
code that involves flow control interrupts. I don't see any advantage
in one vs the other. Pending interrupts remain queued so as soon as the
_EINT() hits, they'll get serviced. Fixed interrupt latency has already
been compromised as the interrupt routines for sending and receiving
characters don't enable interrupts inside their service routines.
3. Are You AWARE that below code blocks main loop and UARTR0_RxBuf processing
Of course. Unless you plan on implementing some complex management
scheme that leaves printf(), puts() and friends working when you're
done, if you can't put a character in the buffer, you can't transmit.
What are you supposed to do with it? Throw it away? You'll lose just
about every character you want to send after whatever your buffer size
is. If you need it (and occasionally some of my code does), you can
write a function that returns 0 or 1depending on if there's space
available in the buffer. If there's no space, don't call putcharx().
printf() and friends make no such checks, so you'll be limited to using
your own formatting routines.
in function like getcharx(int data), and all other stuff untill sending
completes. You will notice it when operation both uarts simultanously!
THE REASON is in a code: while (tmphead == UART0_TxTail);
I am looking for way around to fix it ( apart from increasing txbuffer) but so
far I am not sucessful. I am trying something like this:
while (tmphead == UART0_TxTail){
Do_everything_what_is_in_MainLoop();
}
I think the best and universal solution would be setjmp() to main loop and
after completing return back.
I would question your architecture at this point, and suggest that is
likely time to refactor, or switch to a strategy that involves doing
your "mainloop" processing in interrupt code. If you are generating so
much continuous output that you cannot service your other requirements
then interrupt driven output may not be the correct solution for your
problem.
Very few of the projects that I work on involve hard realtime
requirements, so if I need to output 40 characters and the output buffer
is 16 characters, it can afford to wait. If an I/O needs to be sampled
on a regular basis (as an example), it would likely go into a timer
routine, and either handle the complete processing in the ISR, or put
the data in a queue to be processed in a non-time critical section.
robert
On Thursday 05 of February 2004 01:18, J.C. Wren wrote:
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
-------------------------------------------------------
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
