I2C IO Expander for HD44780

[OmegaRogue]

What would be the best way to go about implementing a driver for the hd44780 in 4/8 bit mode over an 8-bit I2C IO Expander like the PCF8574T as done for arduino in this project, for Raspberry pi, and in go here with gobot, and standalone here and here?

After reviewing the Project Design and Guidelines, it's not completly clear to me what the intended way to do this is.

Some ways I can think of would be:

• making a new driver that uses the hd44780 driver code but has code to use the IO Expander instead of a direct pin connection,
• changing the existing driver to allow for both direct usage and usage over I2C,
• or maybe to implement I2C IO Expanders in the conn/i2c module.

Currently, I'm using gobot to drive my LCD, though this adds redundancy as both periph and gobot are packages for the same or at least similar purposes and i would like to keep my dependencies to a minimum to keep a small overhead in my project.

[maruel]

I generally favor composable components.

I see that the current hd44780 New() function takes 6 pins as input; https://pkg.go.dev/periph.io/x/devices/v3/hd44780#New

If you were to use a IO expander, I would expect it to expose gpio.Pin pins. Something like what https://pkg.go.dev/periph.io/x/devices/v3@v3.6.7/rainbowhat#Dev.GetBuzzer does but in a more ergonomic and generic way.

Then the caller could:

• setup pcf8574t over I²C
• grab its pin and pass to hd44780.New()

Does this make sense?

[OmegaRogue]

I generally favor composable components.

I see that the current hd44780 New() function takes 6 pins as input; https://pkg.go.dev/periph.io/x/devices/v3/hd44780#New

If you were to use a IO expander, I would expect it to expose gpio.Pin pins. Something like what https://pkg.go.dev/periph.io/x/devices/v3@v3.6.7/rainbowhat#Dev.GetBuzzer does but in a more ergonomic and generic way.

Then the caller could:

• setup pcf8574t over I²C
• grab its pin and pass to hd44780.New()

Does this make sense?

That makes sense, that's about what I was thinking of with

• or maybe to implement I2C IO Expanders in the conn/i2c module.

I'll start working on an implementation right away

[maruel]

What change in conn/i2c did you have in mind specifically? I don't see such need.

[OmegaRogue]

What change in conn/i2c did you have in mind specifically? I don't see such need.

To expose GPIOs over I2C.

I've been running into some problems with the implementation. To expose individual GPIO pins over I2C would mean that every write and read happens individually, which would be pretty inefficient. Most libraries that implement the lcd ove i2c do a batch of reads and writes at once

[maruel]

Ah you mean parallel gpios.

That's something I wanted to do for a long time but I think it belongs to conn/gpio. This is not I²C specific. For example one can read 32 GPIOs at once in https://pkg.go.dev/periph.io/x/host/v3/bcm283x#PinsRead0To31.

[gsexton]

Along the same lines, I opened this issue.

https://github.com/periph/devices/issues/17 Direct Register Access for MCP23xxx

[1995parham]

This parallel gpios can be an interface in conn/gpio and each device (for example pcf8574) can implement that interface. for example:

type Reader32 interface {
    Read0To31() uin32
}
...

does this make sense?