ESP32s. So easy. As well supported as any RaspberryPi.
Proper real time on the metal. Interrupts. Native i2c, i2s, spi, serial with a cross-plane so you can re-route most pins around, depending on the board and a few minor caveats.
Any non-real-time operating system will eventually get a little bit buggy around timing intensive operations like I2C or (especially) SPI. Better to have your GPIO operations performed by a dedicated micro that only handles your serial traffic and whatever pin-twiddling operations you need to do. Ideally, your serial traffic is in a binary protocol like MODBUS-RTU, so your traffic parser is as fast as possible.
Bitbanging I2C or SPI is tedious but generally pretty achievable in a bare-metal application. But unless you're hacking your kernel to force that kind of timing fidelity, bit banging on an RPi running Debian is just impossible.
Sounds like this would be very annoying compared to a SBC. You have typically several SPI, UART, I2C, gpio interfaces on the pin header on usual ARM SBCs. Ready to use from Linux via standard API, using DMA, etc.
I once had a very simple I2C operation performed on an Orange Pi running project nerves. I had to add a try-again loop to the I2C operation, because the underlying OS kept disrupting the I2C timing. I2C is generally run between 100-400 KHz, so you'd think it wouldn't be an issue, but it definitely was. You can get around this by patching the kernel to carve out timing protection for those operations, but speaking as a firmware programmer, if I'm patching the kernel to avoid writing a simple arduino sketch, I've made some pretty deep mistakes.
100 khz is still very fast, with sub-millisecond I2C tranfers possible.
You'll have the same issue on any SBC running Linux. You'd need to carefully use realtime process scheduling, if you want more predictable timing on a general purpose OS for such stringent timing requirements.
What I see a lot of is people trying to cram all sorts of shit into a Pi and expecting everything to work properly. I actually wrote a fairly small event-driven kernel for AVR parts a few years ago called XOC "exec-or-communicate" which could do small real-time tasks easily (combinational logic, state machines, interrupt handling) and delegated complicated ones to a host machine over virtual serial port. It was used for a metering system I developed. The AVR side could withstand a complete host failure and reboot.
> GPIO Zero supports a number of different pin implementations (low-level pin libraries which deal with the GPIO pins directly). By default, the RPi.GPIO library is used (assuming it is installed on your system), but you can optionally specify one to use. For more information, see the API - Pins documentation page.
> One of the pin libraries supported, pigpio, provides the ability to control GPIO pins remotely over the network, which means you can use GPIO Zero to control devices connected to a Raspberry Pi on the network. You can do this from another Raspberry Pi, or even from a PC.
Presumably, e.g. TLS to secure that control channel is your responsibility.
> TTL serial refers to single-ended serial communication using raw transistor voltage levels: "low" for 0 and "high" for 1. [31] UART over TTL serial is a common debug interface for embedded devices.
Proper real time on the metal. Interrupts. Native i2c, i2s, spi, serial with a cross-plane so you can re-route most pins around, depending on the board and a few minor caveats.