Weird problem: 635 and ARM SBC


New member
I've got a weird problem here. I wrote a bunch of code to control a 635 display. Everything works great on Mac OSX. I recompiled it for an ARM SBC and now only commands that have an even (or zero) number of data bytes work. Commands with an odd number of data bytes don't. Clear display works but Set Cursor Style doesn't. And if I write a string, the string needs an even number of characters to work. My code is based off the example-635 code.
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.


New member
Grrr... something wrong with the toolchain

After much hair pulling, I discovered that if I build example-635 with an odd-byte length command using the toolchain that came with the SBC it works fine. But if I try to build it on a toolchain I built for XCode, that command breaks. :mad::mad::mad:


New member

Sometimes clever yet obfuscated C tricks get you into trouble. Turns out the CRC word was being byte swapped and shifted in the outgoing packet for odd length command strings. The following code from cf_packet.c
word *packed_CRC_position;
packed_CRC_position = (word *)&[outgoing_response.data_length];
*packed_CRC_position = get_crc((ubyte *)&outgoing_response,outgoing_response.data_length+2,0xFFFF);
Should really be:
word theCRC = get_crc((ubyte *)&outgoing_response,outgoing_response.data_length+2,0xFFFF);
memcpy(&[outgoing_response.data_length], &theCRC, sizeof(word));
And string.h needs to be included at the top of the file.

CF Tech

Thanks for letting us know the solution.

Please accept my apologies for the code that was not portable across all platforms.

I am glad you have it going though


New member
I registered only to say that I had a whole program developped in C and your changes also saved my life.
It was an embedded Linux OpenWRT, on an ARM 9 processor with a cadency of 200 MHz.

Thanks a lot for posting it.
USB LCD Displays - Graphic and Character LCDs with a Keypad