Go Down

Topic: Strange behaviour with LCD and Serial (Read 647 times) previous topic - next topic

jmlietaer

Nov 07, 2009, 09:15 pm Last Edit: Nov 07, 2009, 11:59 pm by jmlietaer Reason: 1
Hello,

Another strange behaviour through the following sketch:

#include <LiquidCrystal.h>
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);
int sensorPin = 0;
void setup() {
 lcd.begin(16, 2);
 char c[17] = "1234567890123456";
 Serial.begin(9600);
 Serial.print(c);
 lcd.clear();
 lcd.print(c);
 lcd.setCursor(0,1);
 lcd.print("1234567890123456");
 delay(10000);
}
void loop() {
}

Output on the Serial Monitor:
 123456789012345v

Output on the LCD:
 123456789012345v
 123456789012345v

After putting both Serial... lines as comment the output is correct.

I am using 0017 on a MacBook Pro with an Duemilanove ATMEGA328.
LCD is Powertip PC1602Q.

Interaction between Serial and lcd objects ?

Best regards,

J.M.

The Cageybee

#1
Jul 17, 2010, 02:13 am Last Edit: Jul 17, 2010, 02:14 am by cageybeeuk Reason: 1
I exprience strange effects with the LCD library too.

It seems to effect the print class in some way.

For some reason, when using the LCD I get random junk characters. I say random becasuse there's no rhyme or reason to where and when they'll show up, but when it does happen in a sketch, it will always be in the same place and with the same character for that sketch. Trying to work around the problem only moves it to another place.

For example:
Using the ethernet library I was trying to upload some data to my site and had this in my sketch:
client.print(" HTTP/1.1");
Suddenly, the uploads started to fail.
I thought I test what was happening with the serial monitor with:
Serial.print(" HTTP/1.1");
and got back:
HTÞP/1.1
which would explain the upload fails.

I tried to work around the problem by spliting the 'print' up, ie:
client.print(' ');
client.print('H');
client.print('T');, etc, but that just shifted the problem. On startup, the LCD would display a box in place of one of the characters on my startup screen.

So I tried removing all references to the LCD, and sure enough, no more junk/corrupted chars from the serial or ethernet.

I've experienced this problem before with the LCD, with characters being transposed and have overcome it with the workaround described above. It's not really an option here though as it just keeps pushing the problem somewhere else.

Unfortunately I don't have the expertise to solve this. Is there any chance that some one more versed in C/avr assembly or whatever could look into why the LCD library is having adverse effects on the print class.

Regards,
The Cageybee

Go Up