Sure I used the MOD bits. But this is of not much use if you use the internal RC clock. One _could_ check the current clock speed with JTAG or other tools, but this works only for the current device and the current moment. 9600bd was possible then, but with dropouts. When temperature changes after the device is in use for some time, or between different devices, the speed changes/differs so much that you'd need constant recalibration to keep communication between two devices and/or a PC stable and error-free. Since we build up to 30 devices per day (not every day, of course, but if so then time is an issue), calibrating each device or compiling a separate firmware for each is not an option. So we decided to put an 8MHz quartz on it and all problems were gone. Together with the increased speed as bonus.
Even if you have the time to calibrate the device, you should monitor the internal chip temperature (on the 430F1611 this is available as A/D channel) one should take the temp drift into consideration and adjust the divider constantly. JGross ----- Ursprüngliche Nachricht ----- Von: Roberto Padovani An: [email protected] Gesendet am: 11 Jun 2009 11:25:20 Betreff: Re: [Mspgcc-users] problem in comunication UART Hmm...this sounds strange to me, because we have been able to use the UART up to 38400 baud without any problem. Did you check the modulation bit setting? R# 2009/6/10 JMGross <[email protected]>: > > My own experiences with the UART programming is that the internal RC clock is > way too unstable and exact to produce a stable communication. > With 4MHz RC clock I was unable to establish a reliable link with 9600 Baud, > while with the same code and an external 8 MHz quarts even a baudrate of > 115KBaud was no problem. > At least you'll need an external 32KHz clock-quartz and some timer-driven > code to build something like a software-PLL to keep the RC oscillator in the > proper range.
