Oh, … and keep it short. yes. … Plus, another advice to remember is that =if= numerous peripherals are sharing these lines, their combined pull-up resistors (effectively in parallel) could pull these lines High, with too much current.
To tell you the truth, we are looking at another approach to this health indicator. I would prefer some kind of simple I2C approach, like you have described above, exploiting that extremely inexpensive lcd.
However, we already have other lcd’s, and other micro-controller options to drive them. Our architecture is to drive this (first) with a simple arduino running a Ros-Serial node, to pump ros-serial data to the display. The heavy lift is an additional ros node in the Pi which monitors the system’s health and then publishes simple strings to the ros-serial node. For now, we will connect this simple arduino approach to the R-pi through one of the USB ports.
I have to admit that I feel a little dirty using the arduino. We have a lot of success with MBed-compatible boards, especially some from ST-micro, which are extremely powerful, with floating point processing on-chip. … Once this arduino architecture works, we will port it to one of our ST boards.
One more thing ~ ~ I would prefer to use the R-Pi’s I2C bus, which if believe are pin3=sda(1) / pin5=scl(1) … AND … pin27=sda(0) / pin28=scl(0) . HOWEVER I am a little scared of the methodology of programming for these pins, within your Ubiquity software architecture. I believe you use Ubiquity-flavored Kernel-level drivers and Kernel-level applications to communicate with these pins, and associated Ubiquity drivers and Ubiquity services. If true, this presents a steep learning curve.
Please feel free to re-direct my suspicions, if necessary. And, possibly direct me to any documentation to guide me: sample code, how-to’s, etc.