Setting Baud Rates

Jon,

Yes that is the basis of the communications. Set them both to the same baud rate and make sure that you hook the RX of one device to the TX of the other device. If you hook TX to TX and RX to RX, you arent going to get very far! 

-Jason

That sounds great.  I will make sure I hook it up correctly.  One last question.  What's the general rule for selecting a baud rate?  I am transmitting data at 4 Hz so how would I go about selecting a good baud rate?  Is it based on the transmission rate or is it based on the system requirements of the Host MCU?

Take care,

Jon

Jon,

How much data is it? If its a large amount of data, you would need a faster data rate to allow for any data manipulation that you may need to do. You have quite a bit of time(250ms) to get things done. Are you trying to conserve power? Spend lots of time in sleep mode? You can pick a vlaue and experiment with it. If its not going to be much data, the speed may not be all that critical.

If you are going from one transport media to another, make sure you arent trying to recieve faster then you can transmit unless you are going to buffer the data.

-Jason

The data payload is 8 bytes per message.  I am trying to conserve as much power as possible.

Thanks,

Jon

Jon,

For your case I might consider using 9600 baud, using a 32768 Hz quartz crystal ("watch" crystal) as the reference clock.  Does your design already have a 32kHz crystal on the MSP430?

This is a very low power configuration, and it still gives you plenty of communication speed.  Furthermore any device you can find will support that baud rate.

Which MSP430 are you using?

Jeff

Jeff,

I thought I already replied to this post.  I am sorry I didn't.  I am using the MSP430F471x6 or x7.  I am planning on adding a crystal.  Thanks for helping out.

Take care,

Jon

Looking at 9,600 baud rate with a 32KHz crystal I notice the error is pretty high at -21.1/15.2 for TX and -44.3/21.3 for RX.  What does this mean?  Is it important?

Take care,

Jon

Hi Jon,

Yes, I think it is important.  But the error is tolerable for almost all applications.

For TX, the numbers are the worst-case bit transition times considering 0 as exactly on time and -100 as one full bit time too early and +100 as one full bit time too late.  There are two worst cases -- the worst-case early transition and the worst-case late transition (obviously two different transitions).

For RX, the numbers are the worst-case bit sample times (the middle sample of the three samples per bit) considering 0 as middle of the bit with ideal timing and -50 as the beginning of that bit and +50 as the end of that bit.  As with TX, there are two worst cases -- the worst-case early sample and the worst-case late sample.  Unlike the TX however, the RX side has to consider the worst-case synchronization lead and lag, which exacerbate the worst-case early and late samples, respectively.  Hence the RX numbers are worse than the TX numbers.

In the worst case RX for early sample with worst-case sync lead, the middle of the three samples occurs at -44.3% (shown in the table).  The first sample of the three occurs at -59% (not shown in the table), which is during the previous bit.  But it still works since the USCI uses a majority vote of three samples per bit.

What's not in the table is which bit of the frame experiences these worst cases.  If you include this information, you can transform these factors into a limitation of how much clock skew you can tolerate in your communications.  Considering the USCI configured for 9600 baud using a 32768Hz reference, the combined clock skew between the two communication endpoints is 0.4%.  Here clock skew is defined as the difference in clock rate.  If your 32768 Hz clock is 0.1% too fast, the remote endpoint is 0.2% too slow, you will still be able to communicate because the combined skew is 0.3%, which is less than 0.4%.  This analysis assumes the remote endpoint isn't also using baud-rate clock modulation.  Very very few devices do.

If you aren't already bored senseless, you might like to see a spreadsheet I made some time ago about baud rates when using the 32768 Hz reference.  It helped me determine clock skew tolerances.  It also shows how the clock modulation in the original USART (not the USCI) was a little better.  (Fair warning - it's pretty raw.)

Jeff

Jeff,

Wow.  Awesome  Thanks for all the info.  It's defintely going to help.

Take care,

Jon

Hi,

if the two chips are not too far from each other I'd use SPI instead.

JustGreg,

What's your reasoning?

Take care,

Jon

Hi Jon81,

according to the datasheet SPI gives you a bidirectional interface and seems to be easier to implement.

Greg