Hello Andrew,
How does the LVB detect an LCD presence ?
In all the LCD programming I have ever done, it has been just logic levels towards the LCD.
Nothing in return ?
Are you talking to the LCD CPU ?
Oh, it's not clever at all. When you send a command to the LCD, you can subsequently ask the LCD for a READY bit to see if the LCD's done its business. If it takes more than 5ms for the bit to become active, then I shut down all LCD communication until the device is reset. Usually, this failure would happen right at boot when there is an attempt to initialise the LCD. If the LCD for whatever reason throws a wobbler and doesn't respond at any point latterly while we wait for the READY bit, any further attempts are disabled too.
The idea behind this was that I didn't want a different set of code for each of the different options. I could have used the push buttons to do some configuration for this, but without a display, I thought that it would be a bit hit and miss.
Look at the code here http://www.g6lvb.com/Articles/LVBTracker/LVBTrack.c, and do a search on the global variable _bLCDActive. It is initially set to TRUE on a somewhat optimistic start during LCDInit. However you'll see it can be set to FALSE in one place, in LCDWaitReady. Various high level LCD routines won't do anything if _bLCDActive is FALSE.
It is wholely possible to do an optimistic algorithm that merely uses worst case spec sheet timings without ever having to read the LCD at all. That would either have meant plenty of dead time sitting in delay loops (equals slow and sporadic response for other parts of the system) or some complicated state machine. As it is, polling for the ready bit is usually only a few tens of microseconds or so. I guess I also just like the nice warm feeling of actually knowing something's listening. Myself I think it's neater to wait for the ready bit, but I accept it's a personal choice. Ask three software engineers the same question, and you'll get three different answers.
Hope this helps.
73, Howard G6LVB