Hello, I've been trying to get the LCD1602 keyboard module working on my nanopi2, but have encountered some challenges. I'm running debian jessie, updated and upgraded to current. I downloaded the latest matrix.git and ran the makefile successfully, but when I run the matrix-lcd1602_keypad test program, I get random letters on the LCD display. I don't get any initialization errors displayed in the cle when the program runs, but it appears like the lcd module isn't correctly sync'ed or there is some communication error. The LCD responds to the keys, but again all I get is random gibberish on the LCD. Can someone please help me troubleshoot the problem? Thanks, Geoff
LCD 1602 Keyboard
Well, I just ran another package update with apt, and lo and behold the LCD commenced to working. I'm sorry for the false alarm, the moderator should feel free to delete this and the above post should they wish. Geoff
Nevermind, it's stopped working again. For some strange reason, it briefly worked and then stopped working again after the next reboot. I'm guessing that the apt-get update was a coincidence and the issue lies elsewhere. Any idea why this seems to work so intermittently? Faulty LCD module perhaps? Thanks, Geoff
You might get a clue watching the bootup messages. Try copying the non-functioning bootup messages and then do the update and copy the new bootup messages and do a diff on them. Another possibility ... maybe the changes are not being saved to permanent memory. I am using matrix on my NanoPi, but have not tried the display.
Thanks for the suggestion Dave. After playing around some more, it appears that the LCD will work occasionally after running an apt-get call but stop again the next time the LCD test program is invoked. I don't even reboot and it ceases working. I'm suspicious that the code doesn't give sufficient delay after issuing the clear command and characters are being garbled that way but I don't know what role the apt-get call would play in temporarily avoiding this. I'm going to try playing with the code a bit and introduce a short sleep call in the routine. Has anyone else seen this issue with the LCD module??
SOLVED: It turns out that it was a timing issue as suspected. By adding a usleep(2000) after the LCD clear calls in the test program, the LCD started displaying consistently correctly. The datasheet shows a 1.52ms duration for a clear, so something slightly greater than that should work. Reading other forums and posts, it might make sense to program a check on the busy flag posted by the LCD as an alternative to the programmed delay, but that's something I'll investigate later. Perhaps the test program worked on older CPUs with slower cycles, but it seems to be challenged on the NanoPi 2. Nonetheless, I'm incredibly grateful for the matrix library, it's a great starting point.