While testing the CustomCharacter.ino example for the Grove LCD RGB Backlight from Seeed Studio on an Arduino 101 card, there is an extra pixel that appears above an eye of the smiley and the smiley gets shifted one row down also. (see attached picture just below, with some manual changes in the library, while trying to fix the problem)
Actually, depending on the order of the characters assignments, the smiley is finally displayed correctly, such as in the following minimal working example, where the two createChar() assignments have been swapped (1 is before 0) and both smileys are displayed correctly:
#include <Wire.h>
#include "rgb_lcd.h"
rgb_lcd lcd;
byte smiley[8] = {
0b00000,
0b00000,
0b01010,
0b00000,
0b00000,
0b10001,
0b01110,
0b00000
};
void setup()
{
lcd.begin(16, 2);
lcd.createChar(1, smiley);
lcd.createChar(0, smiley);
lcd.setCursor(0, 0);
lcd.write((unsigned char)0);
lcd.write(1);
}
void loop() {}
If I happen to put lcd.createChar(0, smiley); back before lcd.createChar(1, smiley);, the error (the shift in the pixels rows + the extra activated pixel) occurs again for the second smiley.
Could anybody explain why this actually happens and, hopefully, give some way to fix the display?
setup()function showed here is an adaptation of mine of the one original one inCustomCharacter.ino.rgb_lcd::begin(). Such HD44780 compatible displays should to be initialized to 8-bit mode first. But it seems as if the method doesn't do this. However, as the LCD apparently is initialized, this has no consequences. But it is a smell about the quality of the library. -- The methodrgb_lcd::createChar()looks OK. -- I would try to go one level deeper and bypass the library, using I²C directly to gain maximum control. -- What does the display show with your simplified program, both cases: 0 before 1, and 1 before 0? Are both smileys correct or wrong?