Grappig... Ik heb dus ooit een libje geschreven voor die 44780. Uiteraard checked die de busy flag. Fijne daarvan is dat je helemaal niet over timing na hoeft te denken.
Tot op heden slechts 1x een display gehad wat niet wilde. Dat bleek een rotje in het display zelf te zijn - z'n broertje deed (en doet) het prima.
Ja, je kunt je aan de timing houden. Gaan kl*ten met delays enzo. Veel te veel gedoe en al helemaal niet handig als het controllertje meer moet doen dan alleen iets op een display frutten. Die paar extra I/O pinnen? Ach, die heb je tegenwoordig toch zat. En als het echt krap wordt (heel soms gebeurt dat), dan is het met een shift register ook zo opgelost - libje voor, je merkt er in code niks van. Kun je de volledige I/O met 4 pinnen doen (ok, als je met timing gaat hannessen met 3...).
(we hebben er tienduizenden uitstaan, nooit problemen met het display)
Als dat ook tienduizenden dezelfde displays zijn... Dan is dat ook niet zo raar als het eenmaal werkt . Overigens valt het ook niet altijd op - als het 'meestal' goed gaat, zou het zomaar kunnen dat er geen klant over klaagt. Tsja... Prutswerk. Maar dat is dan ook goed genoeg, dat klopt.
Waarom het nou RS485 moet zijn? Dat is alleen maar handig als het ook wat verder weg zit - serieel op TTL of 3V3 is voor 'on board' ook uitstekend te doen. Trix, wat let je: maak een stukkie software wat die LCD controller aanstuurt en ondertussen op z'n UART luistert. Schrijf iets van een 'terminal emulatie' waarin je een wat control spul hebt zitten om bepaalde acties te doen - er is vast nog wel ergens een beschrijving van VT100 ofzo te vinden.
Nadeel daarvan is wel dat het je een UART kost (of wil je het gaan bit-bangen? ). Dat is voor mij doorgaans een veel groter obstakel dan een paar I/O pinnen...