For pure-software projects, where you could just throw an x86 thin client at it for cheaper anyway, yeah the pi4→pi5 upgrade path is quite straightforward. But

For pure-software projects, where you could just throw an x86 thin client at it for cheaper anyway, yeah the pi4→pi5 upgrade path is quite straightforward. But for anything involving raw GPIO, you know, the reason you might want a true embedded board instead of a commodity PC, the pi5 has completely changed the architecture. The GPIO pins used to come straight off the BCM CPU with direct register access, now they're peripherals of the RP1 southbridge IC which is connected over PCIe. Chief in my mind is the rpitx/pifm projects, which (ab)use the DMA pipeline to cram baseband-rate samples into the PWM registers and make a GPIO pin oscillate at radio frequencies. Connect a (bandpass filter, please! and a) piece of wire, and voila, the board becomes a radio transmitter. This simply won't work on the pi5 without a complete rewrite of the core. Someone will have to figure out if the RP1 even offers similar capability, figure out if PCIe packet jitter will screw it up or if there's some buffering possible in the RP1, and rearchitect the whole project around it. However, neither of those projects has seen much activity lately. In other words, it ain't likely to happen. Just keep using 3's and 4's for this. For some stuff, pifmrds for instance, stereo processing really chews through CPU, and precludes running a station-automation package on the same iron. It would be really nice to have a faster CPU wrapped around the same transmit capability, but that's not what the pi5 is. If someone builds a station-in-a-box around this, it'll have a pi5 for the front-end but a pi4 as the actual exciter.