I don't think so - if you needed GPIO on a small x86 the easiest way would be to hook an Arduino / RP2040 to it. That seems like it's still the sweet spot for RPi, esp. the Zero W, if you need small, low-power, full OS and GPIO.

This.

Not really. I've been researching this extensively lately to try to add GPIO to my stack of Dell Wyse 3040s.

Options with mainline linux kernel drivers:

- MCP2221A (i2c + 4x GPIO)

- CP2112 (i2c + GPIO)

Options without kernel support:

- FT232H

- Arduino nano and clones

- Raspberry Pi Pico running some interesting firmware

- ESP32 running something like ESPHome (completely separate from host)

I've chosen the Pico for now and forked the u2if project for firmware and host support[1]. I also put together a generic ESPHome-compatible protocol server in python to tie my widgets to Home Assistant[2].

[1]: https://github.com/peterkeen/u2if

[2]: https://github.com/peterkeen/aioesphomeserver

I have seen a I2C implementation on the RP2040 that works with native support.

https://github.com/Nicolai-Electronics/rp2040-i2c-interface

Yep, that one is pretty cool too. It only does one i2c bus so it seems like it underuses the hardware a bit, but the mainline driver is pretty valuable.

Why do everyone latch onto bit-banging pins from Linux??? Isn't that going to exhibit wildly unpredictable delays? Wouldn't you normally compartmentalize hardware handling into an OS-free or hard-realtime microcontroller and let the uC communicate with host CPU in less-realtime manners?

You can roll your own "RGB temperature sensing modem" and get/set values with `bash` and `expect` over ttyUSB, no one PWM controls RGB LEDs on a gaming keyboard straight from a task tray app. Trying to wrestle GPIO problems that way is going to be unnecessarily hard.

Not sure which part you're referring to, but I agree. The u2if firmware I'm using has an interface type that generates the addressable LED bitstream with the RP2040's PIOs. The host software dumps the pixel color values over USB CDC into a buffer on the RP2040, then when it's done the firmware tells the PIO to read the buffer with DMA and stream out the precisely timed LED bitstream.

Currently it's running in "one light string per PIO" mode but there's an inaccessible mode where one PIO can do up to 8 strings simultaneously. The pins have to be physically adjacent, though, so it's a bit more difficult to set up in a generalized way.

> an inaccessible mode where one PIO can do

Clarification please. I thought inaccessible meant cannot do :)

Well, sure :) It's a function present in the PIO code that isn't called by the current firmware setup.

Cool. Thanks.

Ah, yeah, that’s the right way to do it, but if you can get away with using a Pi you don’t have to write a second program for your Arduino, haha. People who are happy to do it the right way were already well served, right?

A lot of those used cheap Dell minipcs come with serial ports and the slightly biger ones may have a parallel port.