633 serial control

wyofreeride

New member
I am using a 633 serial LCD in a microprocessor based MP3 player project at school. The LCD will be used for status display and controlling the microprocessor through menus in software. I am using a Motorola HCS12. The board that we are using has a RS-232 converter on the board.

The problem that I am having is that when I send data to the LCD, I receive no response. (I have been trying the reset command for testing).

The current packet that I send is as follows
command = 0x05
data_length = 0x03
data[0] = 0x08
data[1] = 0x12
data[2] = 0x63
CRC = 0xFD90

I send the CRC as byte 1, then byte 0, just as the win_test sw does.

The data format is 1 start bit, 8 data bits, and 1 stop bit.
Baud rate 19200

I have looked at the signal (on a logic analyzer) from both the serial port on my computer, and the port I am using on the micropressor, and the actual data sent is the same. The difference is the delay between when one byte is sent and the next byte is sent. with the computer, there is a delay of 3 idle bits (156.25 uS) between each byte sent. I added a delay in my software to match this, and tried it again. I have not gotten any consistent results from the LCD yet. I have to send the reset command several times before it is recognozed, and sometimes it isn't recognized at all. I have also tried to send text command to the LCD with no luck. I am using the win_test software to verify that the CRC I generate is correct, and I know that is working properly.

My questions are:

1) How much delay is needed between each byte sent to the LCD?

2) Is there a way to use an SPI interface to a 633 instead of the RS232?

3) Does anyone have any experience with any of these serial LCD's and a microprocessor

4) The contrast on the LCD also needs to be turned up to an abnormally high level (100%)to display the text, and it still doesn't seem to show all of the pixels of the very top line at full brightness.

Thanks for any help ahead of time. I am using this LCD in a senior design project, and if I can't get it to work I will need to find another LCD (But we really like the features of this one)
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 

CF Tech

Administrator
Thank you for your post.

1) How much delay is needed between each byte sent to the LCD?

0mS

That is implied in the "1 stop bit".

But once you have sent a packet, you should wait for an acknowledge before sending another.

2) Is there a way to use an SPI interface to a 633 instead of the RS232?

The CFA-633 currently only supports RS-232.

4) The contrast on the LCD also needs to be turned up to an abnormally high level (100%) to display the text, and it still doesn't seem to show all of the pixels of the very top line at full brightness.

That is odd. Do you also see that problem with the LCD powered by +5v and connected serially to the PC using 633_WinTest?

Some questions for you :)

Are you sure that the polarity of the RS232 signal is correct from your dev board? Does it go through a "Max-232" style level translator after the UART pin on the processor?

Many times, the CRC is incorrect. Here is a link to a debugger screen shot of the exact bytes in the exact order to send to update the screen Please hard-code to send these bytes to the LCD as a test.

http://www.crystalfontz.com/backlight/633_test_packet.pdf
 

wyofreeride

New member
Thanks for the quick response, here is what I have in response so far

Do you also see that problem with the LCD powered by +5v and connected serially to the PC using 633_WinTest?

That is exactly what I see, this problem showed up in the initial testing of the lcd, before we ever hooked it to the microprocessor(I haven't been able to send any commands to the LCD succesfully and consistently with the uP, only the reset works occasionally) The contrast (using 633_wintest) has to be set to 100% to have all the pixels on the very top line fully lit. That itself seems very odd to me, the reccomendations I have seen were for around 20-30% for optimum veiwing. Could this have something to do with the problem we are having?

Are you sure that the polarity of the RS232 signal is correct from your dev board? Does it go through a "Max-232" style level translator after the UART pin on the processor?

Yes, the board we use has a max-232 on it, so the signals are inverted and at the proper level.

Many times, the CRC is incorrect. Here is a link to a debugger screen shot of the exact bytes in the exact order to send to update the screen Please hard-code to send these bytes to the LCD as a test.

I have tried this sequence with no luck, hard coding each byte, and sending the packet. Just to be sure, should the CRC be sent bit 0 then bit 1 or bit 1 then bit 0. I tried both, and neither worked.

The reason I am wondering is because when I try the reset command the only way I can get any response is to have it sent out bit 1 and then bit 0. When I do get a response from the LCD, it is usually after 10-20 attempts (waiting at least 300mS between each trasmission attempt), but occasionally it will work on the first try. The only command that I have gotten to work is the reset. I have tried several other commands, setting text, clearing the screen etc, check ing them all with the debugger for the correct CRC and nothing has worked.

could this be a problem with the LCD itself??

Thanks
 
USB LCD Displays - Graphic and Character LCDs with a Keypad
Top