Taking all the advices here, now I have this function that actually sends
the character (putchar calls this function)
__attribute__((critical)) void uart_a0_send_char(uint8_t character)
{
while(! (UC0IFG & UCA0TXIFG));
UCA0TXBUF = character;
}
The generated assembly is now
00004d0a <uart_a0_send_char>:
4d0a: 02 12 push r2
4d0c: 32 c2 dint
4d0e: 03 43 nop
4d10: 5e 42 03 00 mov.b &0x0003,r14
4d14: 2e f3 and #2, r14 ;r3 As==10
4d16: fc 27 jz $-6 ;abs 0x4d10
4d18: c2 4f 67 00 mov.b r15, &0x0067
4d1c: 32 41 pop r2
4d1e: 30 41 ret
Which is what it's supposed to be, as the SR gets pushed onto the stack,
dinted/nopped and before the end, it gets popped... (I'm new to this high
level of C coding)
Is this the proper way to handle uart?
On Thu, Nov 17, 2011 at 10:40 AM, JMGross <msp...@grossibaer.de> wrote:
>
> Von: Sergio Campamá
>
> > I'm developing an app that uses heavily printf for debugging... Now, when
> > activated (through a DEBUG macro), the app crashes very rapidly, being
> > random the moment it crashes (almost always it crashes mid sentence)...
>
> One thing I discovered with printf is that the compiler puts the
> parameters on stack,
> but when optimization is on, it does not remove them from stack after the
> call.
> This is only done at the end of the current programming block.
> (e.g. loop exit or function return).
> So all parameters pile up on the stack.
> This caused serieous problems on the 1232 with only 256 bytes ram.
> My solution to this was to enclose all printfs by a do{}while(0);
>
> #define PRINTF(x) do {printf(x);} while(0);
>
> >__dint();
> > while(! (UC0IFG & UCA0TXIFG));
> > UCA0TXBUF =3D character;
> > UC0IFG &=3D ~UCA0TXIFG;
> > __eint();
>
> > I think with this, printf CAN be called from interrupts... Looking at
> the
> > generated assembly, this only adds 3 instructions in total, eint, dint
> and
> > a nop...
>
> The nop is added after the dint to ensure that no interrupt occurs after
> the first
> instruction after the dint. THis is possible because of the pipelining in
> the MSP core.
> (when the dint is executed, the next isntruction is already fetched and an
> interrupt
> might already have been accepted).
> However, it is not necessary to clear UCA0TXIFG, as it is automatically
> cleared
> when writing to UCY0TXBUF, except if the output shift AND TXBUF have been
> empty.
> (in this case, TXBUF is immediately forwarded to the shift register and
> empty again).
>
> In fact, manually clearing it can be dangerous:
> If the USCI was idle, the write to TXBUF clears TXIFG, then its content is
> moved to
> the output and TXIFG is set again. If you manually clear it now, it will
> stay cleared
> forever (well, until you write to TXBUF even if TXIFG is clear, or reset
> the USCI)
>
> This only happens if between the write to TXBUF and the clear of TXIFG a
> tx bit
> clock tick happens. How often this happens depends on the ratio of MCLK and
> the baudrate. And on the likeliness that an interrupt of any kind happens
> between the two instructions.
>
> By blocking the interrupts, you removed one possible source for a lockup,
> but it is still possible that between the two instructions a tick happens.
> Just much less likely than before.
>
> JMGross
>
>
> ------------------------------------------------------------------------------
> 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
>
--
--------------------------------------
Sergio Campamá
sergiocamp...@gmail.com
------------------------------------------------------------------------------
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
