Expander Pins - GPIO Expanders, bus expanders, bus converters #156
Description
The Arduino Nesso-N1 (docs) is an esp32-c6, using two I2C based GPIO Expander chips for some of the basic functionality like user buttons and LCD reset. (Memento is similar).
They've helpfully provided an ExpanderPins class with some utility functions so users can do digitalWrite and read, and convert between:
https://github.com/espressif/arduino-esp32/blob/c0395df7e038fe02186543c32eb6de3d12987636/variants/arduino_nesso_n1/pins_arduino.h#L45-L50
and
https://github.com/espressif/arduino-esp32/blob/c0395df7e038fe02186543c32eb6de3d12987636/variants/arduino_nesso_n1/pins_arduino.h#L140-L142
It's not perfect, as function signatures may still need to change (like in Adafruit GFX), but works reasonably well.
We probably want a similar notion, with bus type + number taken into account (so a third property).
I've currently been unable to define those expander pins for use, although have hardcoded the LCD Reset expander pin for the Nesso display in FW.
It's also brought up the point that we might want to support virtual busses of some kind, imagining the I2C 8-channel Solenoid driver for a second, which has 8 output channels and another 8 mixed use GPIO channels, and reuse the DigitalIO controller functions by passing the digitalio submessage from an i2c component write/update message.
Worth a quick scan of the slack conversation related to the Nesso:
Slack conversation
I wanted to talk Nesso pins, or the PR in general. In the last two days[ they've shifted to include helper functions](https://github.com/espressif/arduino-esp32/pull/12052/files) in the BSP for the battery watchdog timer, so I'll update to that. The real question/issue is how best to store the list of expander pins for WipperSnapper, whether in v1 to force pin numbers > GPIO_COUNT to go through a helper (a bit like the LED on picow is via CYW43), then setup some high pins for the buttons via expanders. That's probably easiest. Alternatively whether to talk about having 5digit pins in schema, and using that for being the i2c address then channel, and any Len>4 pin would be an expander pin. So I'd add the button as "E4402" for example (ch2 addr 44), and if a 3digit address then drop the E, e.g. "10102" (ch2 a:101). The problem with the first option (high integer normal pins) is we need [to translate them](https://github.com/imliubo/arduino-esp32/blob/feat(boards-nesso-n1)/variants/arduino_nesso_n1/pins_arduino.h#L47) to ExpanderPin instances [defined in pins_arduino.h](https://github.com/imliubo/arduino-esp32/blob/feat(boards-nesso-n1)/variants/arduino_nesso_n1/pins_arduino.h#L137-L138), as well as potentially keep a list / converter for each board. V2 we probably want to support pin expanders out the box. (edited)
Brent Rubell
16:22
Does the NESSO use the IO expander for I2C?
Tyeth
16:23
you mean downstream stemmaQT devices via an io expander? if so then no.
Some pins like buttons, lcd reset + backlight, etc are via the expander
Brent Rubell
16:24
I2C is through the expander too?
Tyeth
16:24
no, i2c is not though the expander.
Brent Rubell
16:25
It has a QWIIC connector, is that through the expander?
Tyeth
16:25
the two expanders are on the main i2c bus. The same bus as qwiic
Brent Rubell
16:25
So you can connect a sensor via the STEMMA/QWIIC connector and get its value on IO (edited)
Tyeth
16:25
yep
16:25
that was the proximity debacle last week
Brent Rubell
16:26
Okay, I do not want to support GPIO expanders in WS API v1 but this is a good thing to think about.
💯
1
16:26
Do we need to use the Expander for any MVP functionality (i2c or display) for this board?
Tyeth
16:26
image.png
image.png
16:27
Yes, the buttons would be useful, but ignoring those the display needed one pin as an expander pin.
The changes are currently a draft PR in adafruit GFX
Brent Rubell
16:27
like their usage photos just show the qwiic port connected, do not show GPIO pinouts. I think that’s a good MVP.
image.png
image.png
16:27
Can we ship a version of WS that works with the NESSO’s display and I2C without any more work past what you’ve already done? (edited)
Tyeth
16:28
further mods? If you include my two draft PRs for ada GFX and ST7735/89 repos as already included, then that's enough.
Brent Rubell
16:28
Cool
16:28
Okay, are you blocking on those PRs? Do you need me to review them?
Tyeth
16:29
I would like to swap my custom code that adjusts the battery charger WDT to use the BSP functions instead. the linked PR hasn't been released yet but will be within a fortnight. It might make most sense to bring our BSP fork inline with master, then base the ci-wippersnapper build for nesso on that master (but tagged for us)
Brent Rubell
16:29
@Loren Norman I just remembered (bc looking at arduino nesso n1), we dont have IR blaster functionality in WS yet.. maybe an API v2.1 feature though
16:29
Is that code within WipperSnapper?
16:29
or somewhere else?
Tyeth
16:30
Yes, it's effectively a custom boot section just for the nesso
16:30
https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/pull/840/files#diff-ceef6e0df61c86378e85596a6bb17a70457f153458dac58188ed880877d6b7bfR101
16:31
Should reduce to just battery.begin and enableCharge
Brent Rubell
16:31
Agreed. Could you make that change, then land all the PRs (ci-wippersnapper, ws arduino, adafruit gfx, st display)?
16:31
We’ll be able to pull this all in after they release the BSP.
Tyeth
16:32
As we build from an older tag we'll want to update our BSP fork and cut a new tag for the nesso. I've already done similar for the initial work (using latest upstream in our master fork for the nesso build) (edited)
Brent Rubell
16:33
Why do we need a new tag and can’t update bsp fork ver. only?
Tyeth
16:33
we can, I just mostly use a fixed BSP tag in our fork for consistency
Brent Rubell
16:33
Ok, cool. Just making sure you aren’t building differently for this platform.
👍:skin-tone-2:
1
16:34
Any further questions rn on Nesso N1?
Tyeth
16:35
I quite like the ExpanderPin encapsulation, and wonder about if we need a bus number too for our ideal version, so we can convert easily both ways. Mostly though happy enough (and super pleased they've fixed the helpers/battery confusion)
Brent Rubell
16:35
I think that board would just be a good mvp for i2c+display, seems thats all arduino is using it for in their examples. It didn’t go on sale for black friday so I’m iffy on how many people actually have it, but want to give them ws as a 🎁
16:37
Yeah the expanderpin encapsulation idea is novel. Could you check out an issue on https://github.com/adafruit/Wippersnapper_Protobuf/issues for GPIO expansion and link to the variant and detail what you like about their implementation idea?
New
16:38
I think it’d be an interesting feature to implement for WS API v2.1.
👍:skin-tone-2:
1
16:39
It’s possible we’ll see more advanced ESP32x boards coming down the pipeline soon from vendors that are utilizing all of their available i/o and require gpio expansion (MEMENTO, NESSO N1) (edited)
Tyeth
16:39
yeah we do have a couple worth including down the line
Brent Rubell
16:39
Especially if vendors want to start putting cameras, displays, wifi, etc. It’s worth thinking about
Tyeth
16:41
I'm still a bit torn about including the idea of a virtual bus (expander), for gpio/ds18/etc, so we can reuse most of the controllers as is (they'd just see the digitalio sub message extracted from an i2c message). I think expanders + busses need a bit more thought.
We also currently support the OneWire bus over I2C converter chip, the DS2484, although in V1 we only allow a one to one mapping to a DS18b20 temperature sensor, instead of offering the onewire bus for multiple sensors (Exclusively only one DS18b20 per bus in v1).
There are many other GPIO expanders, and it's worth bearing in mind now that we have SPI displays, we might want SPI based GPIO expanders and other SPI bus related components.