I have programmed a 115200 bps bit banging uart (in ASM) for the MSP430F2013 about 1.5 year ago. The 2013 does not have a UART at all so bit banging is essential. To accomplish this I only used the internal DCO and this approach has failed on 1 device so far (AFAIK the DCO in the 2013 is calibrated at +/-3%) and we've used about 100 to communicate with these microcontrollers. For communication the DCO is set to 8MHz. Faster would probably give you some more precise timing but I cannot use that because of power limitations.

In some cases a UART would however be favorable as the uc does not have to spend all his cycles waiting for the next bit to arrive as soon as the start bit is on the line. Because of this my application cannot handle SPI communication and UART communication at the same time so I had to create a protocol that first 'asks' the microcontroller to make time for UART communication by reacting on any incoming (start?) bit at the UART port with an interrupt. Full duplex bidirectional communication cannot be done this way either.

My guess is that if my 115200 routine runs fine, a 9600 bps UART should do the trick easily.

Regards,
Hendrik

baxtercodeworks wrote:
>
> Can you elaborate a bit? I've used TI code to implement a 9600 baud,
> bit-banged (timer-based) UART on a MSP430F1121a (pretty limited) using
> DCO.
>
> I'm wondering how reliable this is - or whether I should just use a
> faster crystal (I'm using a 32). My application spends most of its
> time in Low Power mode (would a faster crystal take significantly more
> power?), but needs quick response when an event occurs - which could
> come via either the UART (host command) or from a Port event (external
> device.)
>
> I do have your book, so feel free to indicate page#/chapter/ etc.
>
> (also, I'm using two channels on ACLK/Timer_A - one for the UART and
> one as a timeout watchdog.
>
> TIA
>
> --- In msp430@yahoogroups. com, "Tom Baugh" wrote:
> >
>
> >
> > You can run the UART, or a timer-based implementation of one, at 19200
> > from the DCO, but of course that limits the low power mode. Some
> > examples you will see on the web suggest tuning the DCO against a low
> > frequency crystal (32kHz, for example), but we think a better approach
> > is to simply monitor the DCO-based SMCLK against a 32kHz ACLK, and then
> > adjust the UART divisor instead. This avoids all the DCO tuning
> > nonlinearities, and lets you spend the code you save on better UART
> > features ;-).
> >
> > Either way, you will use another timer channel to monitor SMCLK against
> > ACLK, which can trigger certain capture/compare channels, see the
> > datasheet. While we don't give a specific example for monitoring SMCLK
> > in our book, we do brush by this concept along the way.
> >

Start a New Thread