Two rows, forty columns

Eighty characters, thirty-two of them lit

The controller has eighty bytes of display memory laid out as two rows of forty. A 1602 lights the first sixteen of each. The rest is real memory: you can write to it, it remembers what you wrote, and nothing shows.

Row 1 is 0x40

The two rows are forty apart in memory, not sixteen. Row 0 runs from address 0x00 and row 1 from 0x40 — and that is the whole reason setCursor(column, row) exists rather than you counting characters from the top left. The library holds those two numbers in a lookup table and does the addition for you.

It is also why text does not wrap. A string that overruns column 15 keeps going into columns 16 to 39 of the same row, where nothing is lit. It has not been lost and it has not moved to row 1; it is sitting in memory, off the edge.

Scrolling moves the window

scrollDisplayLeft() does not move your text. It moves which sixteen of the forty columns are lit, one column at a time, over both rows at once. Print a message thirty characters long and scroll fourteen times and you have read all of it.

Past forty characters, the controller drops what it cannot store. A message longer than that has to be scrolled by your own code: keep the string in a normal array, print a sixteen-character slice of it, and print a different slice a moment later. That approach works for any length and is usually the one to reach for.

Two instructions worth knowing apart

home() returns the cursor to the top left and undoes any scrolling. It erases nothing.

clear() writes a space into all eighty cells and then goes home. The controller needs about 1.5 ms to do it — forty times longer than any other instruction — and the library sits and waits. That is the flicker people describe when they call it once per loop.