It makes little sense to put code before this forum before the MCU speed is given.

Nearly every LCD display has specific timing requirements, some quite slow, and some not so slow. The delay loops and the equates that permit forum members to know what the actual delays are will prove essential in evaluating the code that drives the LCD interface. These LCD's are not difficult to use. Most often, the delays that are required are not in the width of the 'E' strobe. They're in the length of the open-loop timing of each instruction.

The "usual" problem is failure to coordinate the timing requirements of the LCD, described in the datasheet, with the timing of the driver code. If you lack the datasheet for the specific device with which you are communicating, you are guessing. Often all that's needed is the datasheet for the LCD interface IC, for example the HD44780 or whatever equivalent functional component is present.

Guesses sometimes work, but often fail. This is particularly true in LCD initialization. However, unless you are able to read the busy flag, which, of course, you cannot do until AFTER proper initialization, you have to use worst-case timing for every command, which means you still have to have the datasheet, and you still have to read and understand it.

RE