Today's lesson is don't be a jerk and always breadboard your prototypes first. It doesn't matter how clever you think you are (read: I think I am) nor how many successful circuits you've made in the past, test stuff before committing to a PCB design. It's easy to say that now....
Despite protestations from a few others, I was confident that the uv controller circuit was relatively simple and didn't need breadboarding. After all, we've made a few different circuits with character LCDs, we've made pcbs with transistors and speakers on acting as crude amplifiers. We've made no end of twisty-pots-as-input type devices. It's surely just a case of pulling all these bits together? Why waste time plugging wires into a board when you know it'll work anyway....?
Well, the first attempt just didn't work, and it took me about two hours to discover why - eventually (and reluctantly) making up the entire circuit on a breadboard to do some debugging.
As is often the case, the problem came down to a faulty assumption. I was assuming that because we never read data from the character display, only write to it, that the R/W pin didn't need to be controlled from the PIC - just tie it to ground (the datasheet said 0=write, 1=read) and could save a pin on (or rather save time running a trace back to) the mcu. The only change I made on the breadboard prototype (keeping the original firmware from the non-working board) was that the RW pin was connected (in firmware I left the code for controlling it in the first time around, just never bothered connecting the r/w pin on the LCD to the PIC). Everything else was exactly the same as before.
And there you have it - a working character LCD (complete with blinking LED to show us that the PIC is alive and running code!). And all because of a faulty assumption and a determination to save a few minutes assembly by leaving out the R/W pin.
That worked out well then.