rsta2
Adding Support for RCT FPiGA Audio Hat
Hello all!
My company has recently been preparing to release an audio hat which pairs the Raspberry Pi with a Gowin FPGA and Analog Devices SSM2603 Audio Codec to leverage both the Pi's capability as a well supported SoC platform and the Gowin FPGA's ability to provide powerful, single sample latency audio DSP for developers and tinkerers who would like to get their feet wet with FPGAs as co-processors for SoCs (similar to the Xilinx Zynq(Ultrascale+)).
More info on the hardware at the repo here
I originally started this project as a concept to add real time co-processing to MiniDexed, which after the first hardware spin, I was able to do pretty easily. As I've developed more, I've started to realize that this system may actually function across quite a few use cases more than just synthesis, so I've worked with my company's team to develop this in a way that is production ready. We're currently waiting on a small production batch to come in before we take the plunge and order our first order for release. Still quite a bit of cleanup to do with the Linux driver, HDL library, and example projects, but those should be up over the next few weeks.
Anyhow, I've got a I2S/I2C driver library for both the audio codec and the FPGA interfacing as I earlier needed to do this for the MiniDexed port. Still needs clean up for more general use, but it works really well. I was curious about if the community here would have interest in adding the device support into the circle repository. If so, what would the process be to get this done? I want to make sure that before I go in and clean/augment the driver that I'm doing it in a fashion that would work best for integration into the Circle core library source.
My base assumptions now are that I should:
- Fork the circle repository
- Implement my driver code into that forked repository
- Test my changes on all Pi devices I own (Pi 4, Pi CM4, Pi Zero 2 W, Pi Zero, Pi B, Pi 3, Pi 2).
- After verifying these changes as functional with the hardware and seemingly not conflicting with the rest of circle, clone the development circle branch, implement my changes there, and then submit a pull request.
The only trick being that if nobody here has this hardware they wouldn't be able to verify my changes. Should I offer to send off a hat to someone who manages this repository so they can verify that my addition functions as intended?
Cheers!
It depends. If your driver is only one C++ class and comes with one test program, it could be directly added to the sound library in Circle. You could send a Pull Request for it, like you have suggested. It's not necessary to send the hardware, because I cannot test all devices anyway. I would only test, if the existing I2S codecs still work. But if there would be issue reports for your driver later, I would transfer this to you.
But I guess, that's not the case and you have more code and examples? Then I would suggest to implement this in a separate library, like it was done for example for the camera support here. If you need a special C++ interface to the Circle I2S code, this could be added to Circle. I would need to know your requirements for this.
Thanks for the quick response!
Ultimately we are planning on creating boards for other applications of FPGA integrated with the Pi other than audio, so I think it would be wise to create a separate library for interfacing with these hats so as to not have source “spread all about” after adding support for multiple hats.
Maybe the plan here should be to implement support for the audio codec in the I2S library and then include that as a private object in the FPGA interfacing library? That seems like it would offer the most flexibility come future hardware additions while leaving the codebase clean.