Apr30

You can make FLL in software, this is the basic process.
Count a set number of LFXT/ACLK ticks in DCO/SMCLK ticks: Set a timer (can be the watchdog) to fire every X ticks of ACLK, set another timer to run on SMCLK. Reset both timers. Sample the second timer when the first timer fires.
Now you know how many SMCLK ticks go in X ACLK ticks, since ACLK is derived from the LFXT, you can tune your DCO (SMCLK source) to get closer to the desired value.
 
This of course takes time, time you may not have. But if you can spare a bit, add this FLL before every message you send over UART. If that's too heavy, sample every second or minute. Alternatively (if you don't need the reset on watchdog) have the timers run continuously in the background and do this stuff in the ISR.

The guideline for picking a clock source and the required accuracy and stability is pretty straightforward, but in general, using the DCO is what you want. If you have the crystal in system, the DCO frequency can be compared to it and the bit rate divisor can be adjusted for best approximation.
 
The error rate given describes the accumulated timing error, NOT the unreliability of the line, and can be used to determine whether there is likely to be data errors in transmition due to timing issues.
 
To add a little background, the bits are sent and received in nominally identical time slices. The first edge of the start bit is used to synchronize the process, and, from then on, the receiver examines the line at the middle of each bits allotted time slice. For 8 bit data, with a start and a stop, the total time used is 9.5 bit times, and if the timing slips more than 0.5 bit times in that, then the receiver may lose synchronization on the later bits and the stop bit. This will trigger an error state if the receiver expects the bits faster than the sender provides them, and the bit the receiver sees as the stop isn't the appropriate stop state, and confusion will result from a number of possible ways for the synchronization to fail leading to bits being read as the wrong position in the data.
 
THis 0.5/9.5 ratio means that the maximum difference in bit rate , for reliable operation, is 5.5%.  THis isn't bad, but does require a decent clock  at both ends. If both clocks are off by 3% in different directions, then there will probably be loss of synchronization. This is the total difference, and, if one clock is very close, the other tan take substantially all of the error (this is not an unusual case, but is not always the case)
 
The clocks for the MSP430 that make sense here are, as you said, the DCO and a 32KHz crystal. The Crystal is accurate to about 0.01% worst case. The DCO is accurate to maybe 3% typical. On the other hand, as you noted, due to the need to produce the serial clock by dividing the control clock, at bit rates that are greater than about 5% of the clock rate, there will be bit rates that can not be generated to meet the requirement. For historical reasons, the standard bit rates don't play well with power-of-two frequencies like 32768Hz.
 
The situation is improved (and this is where the more favourable looking that expected error bound for the crystal comes from) by dithering the clock when you can't get an exact match: The basic rate is higher than needed, and some bits are stretched by a clock to minimize the accumulated error. This works well, but, if done at both ends of the line, can fail when the bitrate is about 1/5 of the clock rate (6Kbs with the 32KHz crystal). This is a rough number, not exact, since it depends on the details of how the bit time adjustment is done. If one end is dead stable, and an extra stop bit is thrown in, it works quite well up to  maybe 1/3 of the clock rate (9600bps with a 32KHz crystal).
 
All of that said, I usually just use the factory calibrated DCO frequency and have no problem. I don't even bother with checking the exact frequency.

The lower your source clock frequency, the less accurate you can tune your baud rate. So using a 32kiHz source would be less favourable.
But the crystal is more stable than an RC oscillator (like the DCO), even if the RC oscillator is temperature compensated.
So using a high frequency source (like the DCO) will help you get a more accurate clock, but it would be less stable than using the crystal.
The best way would be to regularly tune your internal oscillator to a stable external crystal clock source. This is where PLL comes in to play.
I think you can use the LFXT as a PLL source to your DCO, but I'm not sure.
 
As you may have noticed, I kept talking about stability and accuracy, not about reliability. If you want your UART to be reliable, you would prefer the baud rate to be as close to the desired baud rate as possible, with as little jitter or drift as possible.
For real world scenarios, that drift and jitter is barely a problem when using a baud rate as low as 9600Bdps.
Also note that in the case of the msp430g2 Launchpad, you cannot go higher without using an external UART to your PC or other peripheral, because the emulator does not support higher baud rates.
 
I'd err on using the DCO over the LFXT, because you can get a better approximation of the desired baud rate.

Free shipping until 9/18/2016.

Free shipping at TI Store through 26-JUNE-2016: http://www.ti.com/lsds/ti/store/power-week-deals.page?HQS=corp-tistore-null-powerweek-adh-lp-null-wwe
 
 

While I was doing research on this I came across Vultr and Scaleway. Don't have any experiences with them, though.
 
 
Vultr
* https://www.vultr.com/pricing/
* 15GB SSD, 768MB RAM
* 1T Traffic
* USD 5 + VAT
 
 
Scaleway
* https://www.scaleway.com/pricing/
* 50GB SSD, 2GB RAM
* Unlimited Traffic
* 2.99 EUR + VAT

While I was doing research on this I came across Vultr and Scaleway. Don't have any experiences with them, though.
 
 
Vultr
* https://www.vultr.com/pricing/
* 15GB SSD, 768MB RAM
* 1T Traffic
* USD 5 + VAT
 
 
Scaleway
* https://www.scaleway.com/pricing/
* 50GB SSD, 2GB RAM
* Unlimited Traffic
* 2.99 EUR + VAT

I just did a clean installation of CCS6.1 and guess what: 

I'm from WIZnet Europe - but this is not intended as advertisement.
Here I just like to make a short tech. comparison:
 
                 W5500            | ENC28J60          | CS8900A
                 ---------------------------------------------
Temp at work:    40

Actually, unlike most small microcontrollers, the msp430 has a von Neumann architecture so it *can* execute code from RAM.
 
All you need to do is program the FLASH to read code over the serial port, store it in RAM, and then execute it.
 
That said, the 10K flash cycle is a minimum, and in practice you will be able to get much more. If the MSP430 flash cells are anything like those used on the AVR, you may get a full order of magnitude more. The folks over at DP wrote some code to re-program the AVR's flash memory continuously, and it took several months to wear out the flash cells.
 
Has anyone ever attempted something similar with the msp430? If not, I think I may sacrifice one of my G2211's for this...

Like most small