Remote LCD Ideas....

Hi, I was looking for some ideas on how to handle a remote faceplate. The faceplate (user interface) will be remote from the main PCB (about 6-8 inches) with a secondary PCB. On this PCB I need a 20x4 LCD and four buttons. Assuming a 4-bit LCD interface, that's 6 conductors for the LCD, 4 for the buttons and 2 for +5/gnd for a total of 12 conductors on a ribbon cable. Seems cumbersome. I also don't have enough pins on my PIC for this and I'd prefer not to go to a larger PIC.

I was thinking an I2C buss with a I2C capable display and I2C 4 I/O expander for the buttons, that would be just 4 conductors to the faceplate.

The other option would be a I2C 16 I/O expander, which is less than $2, and use that to drive a plain parallel LCD and the buttons. A bit trickier to code.

I like the option of the LCD with integrated I2C, but they are rare which tells me that this is not how this is usually done. i did find this one at Digi ==> **broken link removed**

Any thoughts?

Thanks

I would use a Peripheral Interface Controller to make a slave I²C device that drives the display and reads the keys. The Pic I would use is a 16F88 as this has slave I²C capabilities an internal clock and enough I/O to provide a single chip solution.

I have been thinking of building just such a board but it kinda got put on the back burner. If you decide to go this route and aren't in a real rush, I could help with the code.

Mike.

Hi Mark,
I just have a question if you don't mind, What's the part number and source for the I2C 16 I/O expander you mentioned ?
Thanks,
Bruce

use a MCP23016 I2C Port Expander..ww1.microchip.com/downloads/en/DeviceDoc/20090C.pdf
The pins are individually configurable as inputs or outputs...

The Shift1-LCD PCB will do what you need, it will drive a 4x20 display no problems from 1 PIC output pin. All it needs is a shift register IC and 2 resistors and 2 caps.

As for the 4 buttons, you can connect them to the D4-D7 data pins of the LCD, and connect the other side of the buttons to one common which comes back to the PIC on one input pin.

So you get 4x20 LCD and 4 buttons using just 2 PIC pins.

There is more info in this thread;
https://www.electro-tech-online.com/threads/shift1-system-drives-lcd-from-1-pic-pin.99634/

The shift1 PCB makes it really quick to get a LCD application up and running or to make a smart display or remote display etc. I've got plenty of kits made up for them and good bulk discounts too.

Brevor said:

Hi Mark,
I just have a question if you don't mind, What's the part number and source for the I2C 16 I/O expander you mentioned ?
Thanks,
Bruce

Click to expand...

This (28 QFN); Digi-Key - MCP23017-E/ML-ND (Manufacturer - MCP23017-E/ML)

or this (28 TSSOP); Digi-Key - SX1503I091CT-ND (Manufacturer - SX1503I091TRT)

or this (28 DIP); Digi-Key - MCP23017-E/SP-ND (Manufacturer - MCP23017-E/SP)

Type in "expander" in Digi-keys' search and you will come up with just shy of a pantload of choices.

Mr RB said:

The Shift1-LCD PCB will do what you need, it will drive a 4x20 display no problems from 1 PIC output pin. All it needs is a shift register IC and 2 resistors and 2 caps.

As for the 4 buttons, you can connect them to the D4-D7 data pins of the LCD, and connect the other side of the buttons to one common which comes back to the PIC on one input pin.

So you get 4x20 LCD and 4 buttons using just 2 PIC pins.

There is more info in this thread;
https://www.electro-tech-online.com/threads/shift1-system-drives-lcd-from-1-pic-pin.99634/

The shift1 PCB makes it really quick to get a LCD application up and running or to make a smart display or remote display etc. I've got plenty of kits made up for them and good bulk discounts too.

Click to expand...

OK, now that's just cool. One question, do you think that the capacitance of an 8" or so ribbon cable feeding the data and power would be of any concern, ie: mess with the RC network timings?

Pommie said:

I would use a Peripheral Interface Controller to make a slave I²C device that drives the display and reads the keys. The Pic I would use is a 16F88 as this has slave I²C capabilities an internal clock and enough I/O to provide a single chip solution.

I have been thinking of building just such a board but it kinda got put on the back burner. If you decide to go this route and aren't in a real rush, I could help with the code.

Mike.

Click to expand...

If I go with this option I would probably go with a 8F13K22 as I'm using Swordfish and would need to stick within the 18F family.

This is an interesting idea as I could run the entire user interface / menu code in the "sub" PIC. Instead of dealing with button interrupts in the main PIC I could just pass back updated configuration parameters. Less multitasking required. I think I like it.

I'll have to go read up on I2C slave mode.

I would just use plain old SPI, with your 74HC595. Of course, its not one-wire But with 5 wires, a serial-parallel, and a parallel to serial (74HC164?), you'll get to control your LCD, and read in 8 buttons. Add another line as an interupt for the buttons, so you're up to 6, and thats pretty simple, fast (hardware or software SPI), and the actual code would just be two loops, one for reading, and one for writing, or for 'true SPI', both in the same routine.

Blueteeth

No fancy (and very clever!!) RC networks for one-wire, cheap and dandy. Easily expandable by cascading shift registers too.

Mark_R said:

OK, now that's just cool. One question, do you think that the capacitance of an 8" or so ribbon cable feeding the data and power would be of any concern, ie: mess with the RC network timings?

Click to expand...

Thanks, and as for the cable capacitance causing problems, possibly. I have built many Shift1-LCD setups so far some with over a foot of cable but not ribbon cable. My main test setup connects a Shift1-LCD slave to a PIC on a MikroE EasyPIC4 pcb, total tracks and cabling over a foot and never a problem.

The single wire signal sent by the PIC is driven direct from PIC pin (a low source impedance) which reduces the problem of cable capacitance. Also that cable capacitance will cause a delay on the start of the 1uS pulse (the shortest pulse), but a similar delay on the end of the 1uS pulse due to the PIC pin having similar high-low drive impedances. So it's still basically a 1uS pulse.

The 1uS pulse is cleaned at the receiving end by the schmidt input of the 74HC595 and the length of the 1uS pulse is not that critical for the system to work, as long as the 1uS pulse does not become longer than say 3 uS there is no problem.

So all in all the system is not too fussy, and 1uS is a fairly slow data speed by modern cable standards anyway.

Thanks Roman.
Even if I don't use it in this project I think I'll prototype it just to see it work. For use on this project I would have to test it at -10C and +60C to make sure the temp swings don't mess with the RC timings.

The wife's going to wonder why I have the protoboard in the oven

Mark_R said:

If I go with this option I would probably go with a 8F13K22 as I'm using Swordfish and would need to stick within the 18F family.

This is an interesting idea as I could run the entire user interface / menu code in the "sub" PIC. Instead of dealing with button interrupts in the main PIC I could just pass back updated configuration parameters. Less multitasking required. I think I like it.

I'll have to go read up on I2C slave mode.

Click to expand...

Strike that, that won't work. I have a SD card bootloader on the main PIC, which means I couldn't update the UI with a firmware release.

Just make it a peripheral controller then. Write command/data and read keys.

A weird coincidence, an example supplied with boostC is a slave I²C LCD controller. I was looking for something else earlier and noticed it.

Mike.

Pommie said:

Just make it a peripheral controller then. Write command/data and read keys.

A weird coincidence, an example supplied with boostC is a slave I²C LCD controller. I was looking for something else earlier and noticed it.

Mike.

Click to expand...

Hi Mike,
It seems to boil down to the following general options;
1- Use an I2C enabled LCD and a I2C 4 bit port expander for the buttons.
2- Use an I2C 12 bit port expander and run a regular parallel LCD and buttons from it.
3- Go with a peripheral controller for the buttons and LCD.

Option #1 would be super simple to implement, but carries about a $3 price penalty. Considering the scope of the project the $3 is not that big of a concern, but what is a concern is that the I2C displays are less common and not mechanically interchangeable. If the chosen display became unavailable it wold mean a redesign of the board. That probably makes this option a no-go.

Option #2 & #3 are about the same price. I think #2 would be easier to code but option #3 could offer the option to provide feedback to the user during the bootload process of the main PIC, which is currently being provided by a couple of dedicated blinking LEDs. (granted, that idea definitely falls in the category of feature creep )

Any other compelling reasons to go with a perepreal controller Vs. a port expander?

Maybe just use a cheap shift register and 3 PIC pins to control it. That removes any RC timing issues, is much easier to control than I2C (and faster) and of course is about your cheapest option.

I also think of a shift register as much more reliable than a port expander IC or peripheral controller, because it doesn't require special setup, doesn't have "modes" or internal processing or timing issues etc.