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)

Example of 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] = {

void setup() 
    lcd.begin(16, 2);
    lcd.createChar(1, smiley);
    lcd.createChar(0, smiley);
    lcd.setCursor(0, 0);
    lcd.write((unsigned char)0);

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?

  • 1
    There is an additional pixel row above the pattern you defined, and the last row is missing. You seem to have a one-off error in your code. May 9 at 6:10
  • @thebusybee: Indeed! I did not spot that fact. I could not tell why that self-defined character is not displayed properly. I have checked the "frownie" character at the same location, for example, and that one is displayed correctly.
    – Olivier
    May 9 at 7:38
  • If the shown code reproduces the issue (the display does not match the code), then I'd say the library is faulty. Their initialization code looks wrong to me. You might want to correct it, do some research. May 11 at 14:36
  • OK. The setup() function showed here is an adaptation of mine of the one original one in CustomCharacter.ino.
    – Olivier
    May 11 at 14:42
  • Well, I mean 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 method rgb_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? May 12 at 7:20


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.