Page 1 of 1

Unwanted character inserted at start of string after move

Posted: Thu Nov 29, 2007 11:42 pm
by Crosius
I am using a LK202-24 (LCD0821) with a PICAXE 18X.
The PICAXE 18X has a writei2c command for sending data to the bus.

A device running at 400 kHz and 8-bit addresses is initialized with the command:

i2cslave $50, i2cfast, i2cbyte

After that, the syntax is pretty simple, writei2c requires the starting offset and the data to be written:

writei2c 0,("String Goes Here")

When I perform any non-printing activity (any 254 command) it performs correctly, but the next character I print will appear along with the character below:

_____
_____
*****
__***
____*
_____
_____
_**__

This character appears to be one of the elements of the default start screen graphic, and appears at the current cursor location, causing the output I want displayed to be shifted to the right by one character.

Anyone have any ideas what is going on?

Posted: Fri Nov 30, 2007 9:16 am
by Raquel
Hello Crosius,

Thanks for your post.

Can you tell me the succession of command and string you are sending?

Posted: Fri Nov 30, 2007 9:26 am
by Clark
Hi Crosius,

Thanks for your question, I believe my colleague has asked for a little more information about you problem; on that note I'd like to add a couple questions. First, I am a little confused about which LCD you are using, is it the LK202-24 or the LCD0821, or are you working with both? Second, what speed are you communicating to the display(s) at; is it indeed 400kHz? This information will help us better diagnose your problem, and hopefully find a solution.

Thanks,

Troy

Posted: Fri Nov 30, 2007 10:55 am
by Crosius
The manual I have says LCD0821, rev 2.0. I can run the LCD at 100 or 400 kHz and the strange character is still displayed. I am using 10k pull-up resistors & have checked that the system is getting 5v signals.

It seems to be that any command with the 254($FE) prefix will display the character at the location of the cursor at the conclusion of that command.

Any non-printing single character, like a CR ($0D) can overwrite the strange character, but any cursor move command will produce it again.

The commands I am sending look like this:

Code: Select all

' Initialise the device at $50 to operate at 400kHz & use 8-bit addresses
i2cslave $50, i2cfast, i2cbyte  

' Route query results to i2c read buffer (Commenting this line out has no effect)
writei2c 0,(254,160,0)

writei2c 0,($FE,$52)		' Autoscroll OFF
writei2c 0,($FE,$44)		' Autowrap OFF

writei2c 0,($FE,$58)		' New Page
writei2c 0,($FE,$48)		' Cursor HOME (row 1, col 1)

writei2c 0,("Line 1",$0A,"Line 2")          ' This line will display the strange char:
                                                         '#Line 1
                                                         'Line 2
' writei2c 0,($0D,"Line 1",$0A,"Line 2")  ' This line will overwrite it.

Posted: Fri Nov 30, 2007 3:15 pm
by Raquel
Can I assume that when you first turn the display on, it has a splash screen ("Matrix Orbital")? Are you able to clear it after sending $FE, $58? I wonder if your commands are actually being executed.

The strange character is custom character $0. In any instance that the display sees $0 without the command prefix ($FE), or it being a part of command parameter, then the character is drawn on the screen.

Posted: Fri Nov 30, 2007 3:47 pm
by Crosius
When the screen powers on, I see a graphic of the Matrix Orbital Logo constructed out of the default custom characters.

I wrote a couple of very simple code blocks for testing and the behaviour isn't consistent. I'm beginning to think it has to do with the i2c functions in the PICAXE firmware.

When I issue nothing but a single "clear screen" command - the screen clears correctly, the cursor jumps to the home position, but a $00 character is displayed before I tell the display to show any other characters.

but if I issue a "move" command, the cursor moves without displaying a $00, until I send a displayed character, at which point the character is preceded by a $00 char.

Posted: Fri Nov 30, 2007 4:07 pm
by Raquel
Hmm, that is odd. I wonder if you can scope the signals out. Maybe PICAXE is sending something that is not expected. Also, make note that maybe when using strings, PICAXE is appending a null character which could be the reason why you see the $0 character.

Let me know what you find.

Posted: Fri Nov 30, 2007 4:57 pm
by Crosius
I just swapped the 18X chip for a PICAXE 28X1, which has hardware support for I2C, instead of using the software functions. I did this to determine if the firmware routines in the 18X were generating the spurious $00 characters.

The screen's behaviour is the same with the 28X1 - the spurious $00 characters crop up in the same places, whether I used the hardware functions or the software functions.

Whatever the issue is, it's not in the PICAXE unless the hardware routines are also sending a null character. And if the chip were appending a null, wouldn't the $00 character appear after the string? Wouldn't it be prepending the null to generate a leading $00?

Could it be a problem with the I2C bus I built? Would the 10k pull-up resistors I am using create issues?

Unfortunately, I can't scope the signal, I am a hobbyist without a scope.

Posted: Sat Dec 01, 2007 11:31 am
by Crosius
I solved this issue. It was due to a conflict between the PICAXE documentation & the way the LCD parses data from the bus.

The PICAXE documentation said that I had to send an offset byte and then data:

hi2cout 0,("Data")

But the LCD was interpreting that leading 0 as a $00 character & printing it.

I didn't realise that the command without the offset:

hi2cout ("Data")

was legal, because it's not shown in any example code.

The PICAXE was sending somethine extra, but only because I was telling it to do so. A perfect example of software doing exactly what I asked, not what I wanted.

The LCD is working great now. Thanks for the sounding board and ideas, they helped a lot.

Posted: Mon Dec 03, 2007 8:56 am
by Clark
Hi Crosius,

It's great to hear that you've got your LCD up and running! Code always seems to have the rather unintelligent nature of doing only what you tell it to, but it's good to see that you've got it figured out. We're always glad to provide developers what ever help we can to realize the full potential of our displays; if you run into any more trouble along the way, feel free to post here anytime.

Thanks,

Troy