> Am 16.11.2011 18:35, schrieb Sergio Campamá:
>> Ok, I got it working now...
>>
>> With the interrupt disable/enable in putchar, as in the following code, the
>> app never crashes
>>
>> __dint();
>> while(! (UC0IFG & UCA0TXIFG));
>> UCA0TXBUF = character;
>> UC0IFG &= ~UCA0TXIFG;
>
> this flag is cleared automatically by the hardware (just delete that line).
>
> and the order you doing it here could have bad consequences too. in case
> the CPU is run very slowly and the UART is very fast, the byte could be
> completely sent before you clear the flag so for the next round it would
> lock forever as the TXIFG won't get set again.
>
What would the correct order to transmit in uart be? This is taken from many TI
examples on transmitting over uart
The code I posted isn't actually in putchar, but in a uart library function
called send byte, which gets called by putchar. I hope to release it someday as
open source...
> the same problem could occur if the hardware uses a buffer and is ready
> again immediately after the write to the TX buffer. The MSP430 UART
> module actualy has a buffer (internal shift register and the value
> mapped to the TXD/RXD memory locations). so this could explain if you
> had problems with this code while interrupts are enabled...
>
>
>> __eint();
>>
>> I think with this, printf CAN be called from interrupts...
>
> this version could have unfortunate effects.. the EINT at the end
> enables interrupts - even within an interrupt handler. so nested
> interrupts are allowed...
>
> functions that lock interrupts and should be safe for use in interrupts
> and foreground best use the critical function attribute:
>
> __attribute__((critical)) int putchar(int c) {…}
Where is this documented? I could not find the definition for it on the inter
webs….
Also, can I define this attribute for variables also? So that the write method
for them are atomic?
>
> that way, the compiler will generate code to disable the interrupts and
> restore that state afterwards.
>
> anyway, even if putchar works from interrupts, if foreground and
> interrupts output data at the "same time" you'll get a weird mix of
> characters on the receiver's side of the wire…
>
Haha, yeah, it gets pretty messed up, but is only for debugging.
Thanks for the tips!
> chris
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
