I like this idea, but what do you do for GPIO (and SPI, I2C etc.)?
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.
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.
Found this:
"Ryanteck RTk.GPIO (PC GPIO Interface)" https://uk.pi-supply.com/products/ryanteck-rtk-gpio-pc-gpio-...
gpiozero > Remote GPIO: https://gpiozero.readthedocs.io/en/stable/remote_gpio.html :
> 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.
Parallel ports > Pinouts: https://en.wikipedia.org/wiki/Parallel_port#Pinouts
"The parallel port" (2023) https://news.ycombinator.com/item?id=34585216
Serial port: https://en.wikipedia.org/wiki/Serial_port
UART: Universal asynchronous receiver-transmitter:
Serial TTL: https://en.wikipedia.org/wiki/Transistor%E2%80%93transistor_... :
> 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.
"Possible to use a 9 Pin Serial port as "GPIO" using ioctl()?" https://stackoverflow.com/questions/27789099/possible-to-use...
D-subminiature > Typical applications > Communications ports: https://en.wikipedia.org/wiki/D-subminiature#Communications_...
Crosstalk: https://en.wikipedia.org/wiki/Crosstalk
"Can you hotwire this computer to transmit a tone through the radio?" https://www.getyarn.io/yarn-clip/aac07d77-c6d6-4da7-bdd3-b93... https://en.wikipedia.org/wiki/Air-gap_malware