I want to share my experience with a 16X2 LCD (1602) display purchased through AliExpress a few weeks ago. The seller on eBay and AliExpress is Surenoo (
www.surenoo.com) and the OEM is apparently Raylid (
www.raylid.com). The specific Surenoo model is SLC1602F, and the Raylid model is RSI1602***.01) which is supposedly a newer model dated 2012. Its attractive feature is serial communication with UART (RS232 type for 5V). There is also an "RS232" model that can use +/- 12V. If you order one, and want 5-volt compatibility be sure to get the UART version.
The datasheet from Raylid is in .rar format, and I had difficulty decompressing that. From what I was able to decipher, the datasheets are the same.
It reminded me of a 20X4 display I got from SparkFun a few years ago. Control codes and putting ASCII characters are/were virtually the same. Pictures of the 1602 and SF 20X4 are attached. One notable difference is that the SF device had an accessible PIC16Fxxx chip, which I upgraded to a PIC16F1827 and wrote my own code for it. That was posted on the SF site, but has since been removed. The current device is all COB; although, there are what look like pogo pads on the lower left side, which could probably be used for programming, if one knew what was for what and the type of MCU.
Major Takes:
1) All commands at two-part. One sends 0xAA + a CMD code. That is true even for ASCII, except after the initial command (0xAA + 0x25) one can send a string of ASCII characters followed by a mandatory 0x0D terminator. For a single ASCII character, that is 4 transmissions.
2) The baud is fixed at 9600 and, unlike the SF device, cannot be changed. I like to go faster and can operate the SF display regularly at 38,400 baud. It was tested at 76,800 baud without problems.
3) Unlike usual UART displays, one must monitor the "BUSY" pin (set = busy). That makes it a 2-wire, rather than 1-wire connection to the MCU. Presumably, one could implement a delay, such as 40 usec, and not monitor the busy pin, but I did not investigate that further.
4) Under what I presume is the MCU COB is a chip that looks like a crystal. It is labeled 8.0, which I assume is 8 MHz.
5) Backlight intensity can be controlled in firmware (0xAA 0x13 n (n=0...0xFF)). I found
n=0x04 n=0x40 to be plenty bright.
6) One cannot alter the contrast. That is a significant inconvenience for me.
7) The biggest flaw I experienced was that the display frequently locked up when doing development and reprogramming the main MCU. I included a screen blink in the attached code to help identify when that happens. A "reset" of the display does not help, as the display doesn't respond to anything. The only way I found to get around such lock-ups was to toggle power to the board. The SF display had the same problem, which is the main reason I replaced the MCU, changed the crystal, and used my own code. Other users responding on the SF site experienced the same problem, which is why I posted my hardware revisions and code there. SF told me that product was made under contract with a company apparently in China, and once its stock was sold, it was discontinuing the product. I wonder whether Raylid was the "contractor" that SF used.
There also a keyboard functionality (5 keys + GND) that will send a number to the MCU. I did not evaluate that.
(Edit: Ha, ha, I forgot turn turn off smilies. Should be #eight) ).
Attachments:
1) Front and back pictures of the 16X2 display
2) Front and back picture of the SF 20X4 display
3) Operating picture of the display. The artifacts are due to my lack of familiarity with my camera. The screen is bright blue, and except for too much contrast, is quite clear.
4) MPLAB Assembly code used for testing (change the extension to .asm if you want something more readable in MPLab)
Home
Help
Search
Login
Register
