I have an existing installation that already does a lot. Pi4 8GB in a tall case to fit a heatpipe-and-fan CPU cooler, running a regularly updated Raspbian desktop as a casual "PC replacement". (no matter what I do, I can't get the CPU temp to vary more than about 2 degrees C; I like this CPU cooler!) A roughly 4-inch 40-pin ribbon cable gets the GPIO's out of the case and onto a custom PCB so that the Pi can talk to and sometimes reprogram a couple of microcontrollers that themselves modify how the monitor works. A second connector in the middle of the ribbon cable just barely clears the case, and currently just has some single pins in it to power the CPU fan, but it *is* a full 40-pin connector.
Audio comes from a stereo pair of 16-ohm "junk drawer" speakers that need some drastic midrange taming, which the Pi is currently doing as part of a custom ALSA config, before sending it to a 16-bit USB DAC and a separate amp with a scratchy volume knob that is powered from the 12V rail of an ATX PC supply that also feeds a buck converter for the Pi and microcontrollers. The ATX 5V rail is maxed out with LED strips, controlled by one of those micros.
Having used that rig for a while, I'd like to do a little bit more audio processing now, so I've been looking at some external DSP options to replace the custom ALSA config and then some. And while the Beocreate isn't the cheapest possibility, it looks like it might solve some other problems as well by replacing the old amp and buck converter, and provide for some future subwoofers if I ever get there...if I can hook it up around my over-height cooler and make all of the GPIO's work.
For the Pi's GPIO, here's what I have already, with the Beocreate's connections tentatively tacked on as "HF_BRY_xxx":
The Pi's 40-pin GPIO header is on the left, and one of the microcontrollers is on the right. The other microcontroller isn't as closely connected to the Pi, working more with the first micro instead, but it does have a programming interface directly from the Pi, as "VGA_[VPP,PGC,PGD]"
The SHDN signal controls the Enable line of the ATX PC supply, driven from an overlay in "/boot/config.txt". Supply on while the OS is running, off when shut down, hence the pile of capacitors to keep it on during a reboot. (kept adding more until it worked)
Total GPIO count for the Pi = 10, which creates a problem because the Beocreate only passes through 9 of them. So while I could rearrange them to fit, I'm still missing one. Can I get the 10th one back somehow?
(they're individually bit-banged as single bits except for UART and SPI, and SPI could be bit-banged as I use it, just a bit slower for something that's hardly ever used but does need to be there)
Or, can I make a GPIO buss as shown in my tentative schematic? The only real problem I see with that is the SPI interface that the Beocreate needs, and that I use to reprogram the primary microcontroller. The actual program for that micro doesn't use SPI and keeps those pins Hi-Z, so that shouldn't be a problem. But is it a problem to reprogram the micro using that interface? It's a different chip-select (actually the reset signal, since reprogramming is done while it's held in reset), and SPI itself is designed to have multiple things share a buss with a chip-select for each, but does the Beocreate do that? Can I stop the DSP comms (not audio) long enough to reprogram my microcontroller, and then restart the DSP comms, maybe as part of the reprogramming script?
Or, can I make a GPIO bus as above, but move my reprogramming pins away from the hardware SPI to, say, GPIO's 12,13,16 (pins 32,33,36), but no other changes from the schematic above? Would that work for the Beocreate?
Any other problems on the Pi side?
For the DSP GPIO, I think I'll need two identical custom modules that each consist of a quadrature encoder with momentary pushbutton, and a red LED. All panel-mounted with flying leads. 4 GPIO's per module, plus the appropriate power connections.
One module controls overall gain (often mislabelled "volume") *before* a limiter, resets that gain to a specific value (determined experimentally and then hard-coded), and indicates limiting. This red LED has a 1k series resistor for "normal brightness", expecting 3.3V. Will that be a problem for a GP Out?
The other module controls the cutoff frequency of a highpass filter, bypasses that highpass, and indicates the bypass. This red LED has a 4.7k series resistor to make it dimmer.
And one more input directly from the Pi, to both bypass the highpass and reset the gain to the same specific value, triggered by a cron job just before a morning alarm.
Total GPIO count for the DSP = 9. Or 8 if the Pi's "cron reset" can be done through the comms. Is that possible with the connections available?