[petsfed]

This is, in almost every respect, the better way.

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.

[megous]

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.

[petsfed]

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.

[megous]

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.