Thanks Hugh, your mail is excellent.
I experimented myself the problem you state that can arise when using a 32K
crystal to generate 9600 baud. I was exchanging data between a PC and a MSP.
The characters generated by the MSP were received OK by the PC but about 5%
of the characters received by the MSP were corrupted. I thought it was due
to a better UART in the PC. Now I see the real problem!!!
I am very interested in your speadsheet.
Best regards,
Claudio
> -----Original Message-----
> From: Hugh Molesworth [SMTP:[email protected]]
> Sent: Wednesday, May 07, 2003 7:59 PM
> To: [email protected]
> Subject: [Mspgcc-users] More on Baud Rates for MSP430
>
> Hi All.
>
> The baud rate calculator at http://mspgcc.sourceforge.net/baudrate.html is
>
> very useful. Unfortunately it seems to contain an error since it doesn't
> take into account the error at the end of the first bit - the start bit -
> and therefore gives non-optimal results. Additionally it reports an
> incorrect % error in the summary. It also calculates the modulator using
> end-bit calculations, not mid-bit which I think might be more useful (see
> below).
>
> MSP-UartCal.pl details:
>
> 1. $max=$error; needs to be moved outside the for() loop so that the first
>
> bit error is considered.
>
> 2. The error % column is incorrect and is a factor of 10x too high by the
> last row:
>
> "$err*100/$t" in the print should be "$err*100/$desired"
>
> Mid-bit or End-bit?
> =============
> This business of baud rates is more complicated than at first is apparent.
>
> On a transmitted signal it would seem reasonable to adjust the bit
> boundaries as close as possible to the nominal. This can be done by either
>
> choosing a crystal that gives exact baud rates or by using inexact baud
> rates and adjusting the error to a minimum via the modulation register. In
>
> the former case typically a 7.3728MHz crystal would be used in place of
> 8MHz giving well-behaved divisors (64 for 115200 baud, 768 for 9600, baud
> and so on). In the latter case choose the lowest integer value and adjust
> the actual bit timing via the modulation register (8MHz @ 9600 baud
> requires a divisor of 833.33, so 833 is used). For high clock rates it is
> clear that the error is so small (ie. error<<2%) that it isn't really
> necessary to use the modulation register correction at all.
>
> With the availability of only a 32.768kHz crystal in low power or low cost
>
> implementations the situation is rather different. Unless the DCO is used
> in PLL mode locked to the crystal (which makes using LPM3 mode difficult
> since the DCO is then off while asleep) the divisors are much more coarse.
>
> 32768kHz @ 9600 baud requires a divisor of 3.41 and the closest integer
> value of 3 will give large errors. This is where the modulation register
> comes in.
>
> As the MSP430 manual states, the BITCLK can be adjusted from bit to bit
> with the modulator to meet timing requirements when a non-integer divisor
> is needed. Timing of each bit is expanded by one BRCLK clock cycle if the
> modulator bit Mi is set. Each time a bit is received or transmitted, the
> next bit in the modulation control register determines the timing for that
>
> bit. A set modulation bit increases the division factor by one while a
> cleared modulation bit maintains the division factor given by UxBR. The
> timing for the start bit is determined by UxBR plus M0, the next bit is
> determined by UxBR plus M1, and so on. The modulation sequence begins with
>
> the LSB. When the character is greater than 8 bits, the modulation
> sequence
> restarts with m0 and continues until all bits are processed. Note that
> values are positive deviation from nominal - ie only 0 or 1.
>
> However, just what are we adjusting? On a transmitted signal it would seem
>
> reasonable to adjust the bit boundaries bit by bit as close as possible to
>
> the nominal boundary value, thus minimising the error. But on a received
> signal the bit boundary is pretty much irrelevant, since the receiver will
>
> only ever sample at the mid-point of each bit period. For this reason,
> from
> the point of view of the receiver we should be minimising the error at the
>
> mid-point, and not the end point, of each bit. This is important because
> it
> turns out that to do this a slightly different value of modulation is
> required for the transmitter and receiver. This would imply that 2
> modulation registers are required, both 10 bits long.
>
> Since there is only a single modulation register, it is probably better to
>
> optimise it for the receiver rather than the transmitter, but this is
> going
> to be application dependent. Some systems will only ever transmit, for
> example. Since all timing is referenced from the falling edge of the start
>
> bit (which triggers the time-to-first-sampling point and affects all
> subsequent sampling points) clearly the most important bit to minimise the
>
> error on is the first (or start) bit. I use a spreadsheet to do these
> calculations, which I could post if anyone is interested in using it.
>
> Hope this is of some help.
> Regards, Hugh
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
