SerLCD baud rate control

Archive SparkFun Site Questions/Comments
1

Hi,

I am having problems with the baud rate control of a 2x16 Serial LCD.

The thing I don’t understand: is the baud rate saved in eeprom, or should we send the baud rate control command (at 9600) at boot time every time the device is powered on? I looked at the firmware but I don’t see anything related to baud rate control in the special_commands() function :-/

I set up the baud rate to 2400 bps, then ran the following code from an arduino:

#include <SoftwareSerial.h>

SoftwareSerial s(10, 2);

void setup() {

pinMode(2, OUTPUT);

s.begin(2400);

s.print(“Bah”);

}

void loop() {

}

It worked, but after a couple of power cycles (the SerLCD is powered by an arduino, powered by USB), it displayed garbled characters because the serLCD appeared to be reverted to 9600 bps. So it appears to be saved and not correctly restored, or not stored at all?

I got it working by sending the baud rate command every time the systems boots:

#include <SoftwareSerial.h>

SoftwareSerial s(10, 2);

void setup() {

pinMode(2, OUTPUT);

delay(200);

s.begin(9600);

s.print(124, BYTE);

s.print(11, BYTE);

delay(200);

s.begin(2400);

s.print(“Bah”);

}

void loop() {

}

Oddly enough, it doesn’t work without the delays (I can understand for the first one - the LCD might be still booting up, but I am not sure as for the second).

Has anybody faced this problem before? Is there a better solution?

Is there a way of permanently setting the default baud rate to avoid this problem?

2

This doesn’t directly answer your question, but if your hardware is capable of talking to the SerLCD at its default 9600 baud, what conceivable reason could you have for changing it to something slower? This appears to be an entirely avoidable problem in your case.

3

my original reply is flagged for my using a forbidden word (??)

in short:

  • hardware UART used for critical stuff => must use software serial for LCD.

  • very critical stuff happening in pin state change/timer interrupts that does not tolerate a delay => must implement software serial in a non-blocking way, without busy loops that freeze all interrupts for the duration of a write.

so the way I do software serial is the following: I write one bit a time, every 62500/2400=26th tick of a timer running at 62.5kHz and used for another (important) task. 9600 is not possible using this approach. 2400 is good because it’s easier to get the timing accuracy right with “long” delays between symbols.

Please note that the problem is reproducible with the simple, standard Arduino code given above - so it’s not related to my peculiar design/environment.