Issue setting backlight on 635 - custom software

[jantman]

I've written a Python class to control a 635USB. (It can be found here).

It's still a work in progress - I don't have keypress handling done yet, and so far I'm not unpacking the return packets from the LCD, just waiting. Everything seems to work fine - clearing screen, writing text, controlling LEDs, etc.*except* for changing the backlight, which does nothing.

The packet it's sending is command 0xE, data length 1, data 0x32, CRC 0xDD9E. Is there something special about the backlight packet that I need to know (and didn't see in the protocol docs)?

Thanks,
Jason

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[CF Tech]

Jason:

Thank you for your post.

I do not know why it would not be working. There is nothing "funky" with the backlight command. It is pretty straight-forward.

Here is what 635_WinTest sends over:

C=x0E(14 = Backlight),L=1,D="\x32",CRC=0xDD9E

which seems to agree with your sample.

Sometimes the languages or serial port classes or file classes do weird things like stop sending when they hit a NUL, translate CR to CR+LF or make the "BEL" character disappear, but in this case none of the characters you are sending should be a control character.

You would want to make sure the port is opened with no handshaking, no translation--that is "raw" mode.

Maybe put some debug code in at the bottom of your sendCommand that will print the values it is sending.

 

[jantman]

Got it working, thanks.

I'm using python, and it turns out I was using struct.pack with a string for data input. Taking a look at the communications with interceptty, I realized that there was an extra 0 byte at the end of the string. Changed a bit of code, and it works like a charm!

 

[jantman]

The link at the top of this post is updated with a working version, which seems to do everything correctly - except it has no button handling right now.

In the next month, I'll have a version up that handles buttons as well, but I'm unsure of whether it will be asynchronous or synchronous. It will probably be quite different, and perhaps use different handling.

Most likely, unlike the current version that writes output directly and immediately, it will be replaced with a class that implements a thread to wait for input and send output every X seconds, from a list of lines to send.

Some code that uses my existing class can be found by browsing through CVS.