I have an existing third party system that has a HD44870 compatible display used for output.

This third party system cannot be changed (for a variety of reasons), and I need to retrofit a device to it, that among other things, 'takes over' the display at times, and returns control to the original circuit at other times.

The display lives on a separate board, connected to the main board with a ribbon cable, and this is my only real option for intercepting the display.

The retrofitted device is an Arduino (Arduino Pro, specifically).

Initially, I was planning to experiment with intercepting the data lines from the original circuit on the Arduino, and passing through the data as appropriate. After some research, I found that this was difficult to achieve reliably while allowing time for other tasks in the code to run.

My current approach has been to have the Arduino permanently connected to the data/control lines of the HD44870 display, and then have the data/control lines from the circuit routed to these via a 74HC367 (tri-state) buffer device, effectively 'cutting off' the original circuit on demand. The Arduino would decide when to return control (by it's connection to the 'output enable' pins of the buffers), and would reconfigure its outputs to be high impedance inputs when releasing control, so as not to pull the data lines up or down while it was not in control. The opposite is also true - while the Arduino is in control, the 74HC637 output enable lines are not active, meaning that they are in a high impedance state.

Unfortunately this has been unsuccessful, with only the Arduino able to control the display. Connections have been confirmed as correct. The Arduino has been using the LiquidCrystal library in 4 bit mode.

A quick-and-dirty fallback would be to use an array of signal relays to switch between the two controllers, but I don't think this is the correct approach for this issue.

For reference, my retrofitted system has no need to know what the original system sent to the display.

So, this leaves me with a few questions:

  • Should the approach described above be effective in performing switching?
  • Are there any existing devices designed to achieve this?
  • Are there any Arduino libraries that may achieve this?
  • Could the switching cause issues with respect to corruption of commands?
  • \$\begingroup\$ Possibly needs to be on the Arduino SE, but this could apply to other controllers too. \$\endgroup\$ – toxicantidote Feb 22 at 3:57
  • \$\begingroup\$ Have you considered emulating HD44780 in your device and simply connecting it between 3rd party system and the display? Your device would then buffer everything which is sent from the 3rd party system, modify it when needed and send the result to display. \$\endgroup\$ – user930473 Feb 23 at 14:25
  • \$\begingroup\$ @user930473 I did look at doing this, but it seemed to computationally and I/O expensive for too little payoff, given the controller has to perform a few other tasks too, such as keypad scanning, sensor monitoring and sending Wiegand data. I did consider a larger controller, but didn't end up pursuing this. \$\endgroup\$ – toxicantidote Mar 1 at 1:32
  • Should the approach described above be effective in performing switching?

Yes, this is exactly how I would do this, but maybe with different IC (see next entry)

  • Are there any existing devices designed to achieve this?

74HC367 is good, but uni-directional. Some devices may require status readback. You can tell by seeing if R/W pin on the LCD ever goes to 1. If it does, you want to use bidirectional switch, like CD4066. Each of them is only 4 channels, so you may want to get two.

  • Are there any Arduino libraries that may achieve this?

Not that I know of -- regular libraries should work, as long as the switch is correct.

  • Could the switching cause issues with respect to corruption of commands?

Yes. There are two possibilities -- one is that extra parts (switch, wiring) will introduce electrical noise. You will need the scope to debug this. But normally, the devices are made fairly robust, so at least at room temperature, everything is likely to work.

The second possible problem is display setup. For example, if devices set LCD to 8 bit mode, but Arduino resets it to 4 bit mode, things are not likely to work. Or device might expect certain entry mode, CGRAM contents, or cursor position -- and your Arduino resets it.

Either way, you want to debug this one step at a time.

  • Unplug Arduino, just leave the buffers. Hard-wire buffers to be enabled. Make sure device can display things.

  • Plug Ardudino, but put a program which disables all the pins and always puts device in control. Make sure device can display things. This will catch things like bad enable polarity, or bad line state while your Arduino is in bootloader. Unplug PC and reboot device a couple of times and make sure it works reliably.

  • Only then enable your library. Do it one function at a time.

  • \$\begingroup\$ I hadn't considered issues such as expecting the LCD to be in certain states. Given some of the shortcuts and cost savings seen on the original board, this would not surprise me. I'll try and do some experimenting this weekend and see what I can find. \$\endgroup\$ – toxicantidote Feb 22 at 5:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.