Open
Description
Moved from arduino/Arduino#4809 by @tablatronix
createChar
does not work after calling setCursor
at least for me, was driving me nuts until I made sure to always do it before moving the cursor.
// would not print my character
lcd.setCursor(numCols-1, 0);
lcd.createChar(1,custombyte);
lcd.write((char)1);
Activity
MythologicalTaco commentedon Jan 15, 2018
I just spent 4+ hours pulling my hair out only to find out that it's most definitely a library issue. Doesn't look like the library is maintained anymore either. I would try Cosa: https://github.com/mikaelpatel/Cosa/tree/master/libraries/HD44780 but I'm already too deep into this project to bother switching out the library right now.
Reading the datasheets for the HD44780, I noticed what appeared to be improper implementation of what the datasheets said, inside this library. That's the only warning I'll give anyone using this.
PaulStoffregen commentedon Jan 15, 2018
Not even a hint of what you believe is incorrect or where (like line numbers) within the library?
MythologicalTaco commentedon Jan 15, 2018
I'm not an electronics engineer so I'm not sure if I was reading the datasheets correctly, but for instance the datasheets would say to read off if the screen was in a busy state before certain operations, and no such check was done from the looks of it. In the case of this, CGRAM and DDRAM share certain state functionality and because of that, doing setCursor() first followed by createChar() fails because the busy state was most likely on. Once again, not sure. You can take a read through the datasheets yourself to verify whether or not I was correct or wrong.
PaulStoffregen commentedon Jan 15, 2018
Are you aware many slightly different datasheets exist for these displays and their controller chips? Without a link to the specific one you're reading, I can't actually read through it myself. (are you seeing a pattern here... the need for details in your messages?)
But I can tell you the datasheets I've seen allow for busy polling or simply a wait time. I and others have made variants of this library which do the busy polling, which does allow for faster updates with some displays. However, simply waiting the maximum busy time is an acceptable approach.
MythologicalTaco commentedon Jan 15, 2018
I was not aware. I was reading the one from SparkFun: https://www.sparkfun.com/datasheets/LCD/HD44780.pdf
Also, I attempted delays between operations and that didn't seem to help.
Also this is what would happen...
I also had this happen...
If the order of commands fired off to the screen gives any hints, that's the best I can give. Frankly I got it to work by reordering and so I'm sticking to that instead of screwing around trying to understand the HD44780 in depth.
PaulStoffregen commentedon Jan 15, 2018
Would you like me (or perhaps anyone else) to try to reproduce this problem?
Imagine if you were reading these messages and you wanted to find and fix the problem. First, you'd have to turn these code fragments into a complete program. Then you'd need to choose a board. This library offers 4 different constructors, so you'd need to guess which of those were used, or perhaps try them all. You'd also need to guess which specific LCD you're using, or maybe buy a collection of them from many vendors and how to get the same or similar enough model.
I'm glad you got things to work for your project. But if you're going to report the problem here, please try to be specific. Details matter. If someone is going to try to investigate and fix a problem, they need all the details of exactly how to recreate the problem.
MythologicalTaco commentedon Jan 15, 2018
If you'd like to attempt to reproduce, go ahead. My posting has a direct relationship to this project: https://github.com/Goodlookinguy/FishLight2
The constructor(rs, enable, d0, d1, d2, d3) was used as per the information I was given by my friend who designed what I'm working on.
PaulStoffregen commentedon Jan 15, 2018
No, this just isn't reasonable. I'm not going to spend the time to pull out just the LCD code from your project, only to try reproducing a problem which may or may not actually be an issue within this library, not to mention doing actual testing without knowing exactly which display you used. Realistically, I do not imagine anyone will spend the time to do this.
Maybe these messages can make you feel better, perhaps relieve some of the frustration you suffered trying to get your specific display to work, but they're not at all constructive for reporting an issue with this library.
MythologicalTaco commentedon Jan 15, 2018
I actually left my message here to suggest trying a different library first if you have problems with this one early on. Cosa seems maintained and this one doesn't. That's what my original message's goal was as well as to illuminate possible issues this library has.
Here's a simplified test I just tried that fails. 👍
bgxlin commentedon Aug 4, 2019
If GoodLookingGuy insert lcd->clear() after lcd->createChar(1, screen) it will run successfully. clear() sets LCD IC to use DDRAM, while createChar() leaves LCD IC in CGRAM mode.
[-]create char after setCursor[/-][+]`createChar` does not work after calling `setCursor`[/+]1 remaining item