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.

what appeared to be improper implementation of what the datasheets said, inside this library.

Not even a hint of what you believe is incorrect or where (like line numbers) within the library?

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.

You can take a read through the datasheets yourself

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.

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...

setCursor(0, 1);
createChar(0, blah); // might load character (who knows)
write(0); // never writes
print("Anything"); // never writes

I also had this happen...

print("Anything");
createChar(0, blah1);
createChar(1, blah2);
write(0); // renders blah1
write(1); // doesn't render blah2

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.

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.

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.

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.

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. 👍

#include "LiquidCrystal.h"

// control panel
#define PIN_CP_RS A0
#define PIN_CP_ENABLE A1
#define PIN_CP_D0 A2
#define PIN_CP_D1 A3
#define PIN_CP_D2 A4
#define PIN_CP_D3 A5

uint8_t clock[] =
{
  0b00000,
  0b01110,
  0b10101,
  0b10101,
  0b11001,
  0b01110,
  0b00000,
  0b00000
};

uint8_t screen[] =
{
  0b00000,
  0b00000,
  0b11111,
  0b10001,
  0b10011,
  0b11111,
  0b00000,
  0b00000
};

LiquidCrystal* lcd;

void setup()
{
  lcd= new LiquidCrystal(
    PIN_CP_RS, PIN_CP_ENABLE,
    PIN_CP_D0, PIN_CP_D1, PIN_CP_D2, PIN_CP_D3);
  lcd->begin(16, 2);
  delay(1000);

  lcd->print("Hello World");
  lcd->setCursor(0, 1);
  lcd->createChar(0, clock);
  lcd->createChar(1, screen);
  lcd->write((uint8_t)0);
  lcd->print(" ");
  lcd->write((uint8_t)1);
  lcd->print(" Testing...");
}

void loop() {}

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.