Go Down

Topic: Need help converting code for 16x2 lcd to work with a 20x4 lcd (Read 163 times) previous topic - next topic


Hey there,
I'm trying to convert a scrollable Arduino LCD menu that was made for a 16x2 LCD, and get it to work with my 20x4 LCD.

I've gotten everything to display, but the cursor still won't move down to rows 3 or 4 on my LCD screen.

Anyone have any ideas?

Sorry, I realize this is a bit long


You have said what the cursor doesn't do.  What it does do is often a clue.

Why not try a simple program that displays a simple message on each of the four rows and then stops.  This should be done entirely in setup() with nothing in loop().



There are constrain functios that constrain the lines to lines 1 and 2.  Maybe those need to be modified?


There are constrain functios that constrain the lines to lines 1 and 2.  Maybe those need to be modified?
It looks much worse than that. There appears to be lots of code that assumes only 2 lines.
Things that look at even/odd , 0 or 1, 1 or 2 etc... and makes decisions based on that.
You can't make that code work with more than a 2 line display without essentially re-writing the cursor and output line logic, which is scattered across several functions.

This reminds me a lot of a common issue that I saw back when I ran a s/w development group back in the 90's.
Often, developers would take short cuts when doing their code if they saw (and assumed) only a single instance would exist and essentially hard code it for that single instance.
Yes, it made the code simpler and quicker to write, but it also made the code very difficult or impossible to adapt to more than one instance.
That same thing tended to happen when they assumed only 2 instances. Or the code was modified from supporting a single instance to 2 instances. The code would make A or B decisions rather than supporting a generic number of instances.
(which is what is happening in this code).

What I noticed is that it wasn't until there was planning to account for 3 or more instances that developers would finally stop taking the short cuts and make it work for the general case of n instances.

Developers would take these shortcuts even when the requirements said that the s/w must support a configurable number of instances.
I eventually starting explicitly putting into the requirements that 3 or more instances must be supported and the issue didn't completely go away but dramatically reduced.

--- bill

Go Up