Finally making some progress in a little devboard that’s targeted at digital audio - a small daughterboard to mount on a carrier for interfacing to various projects like Eurorack modules, guitar stompboxes, etc.
The board has a CV1800B, micro SD socket, USB-C jack, stereo audio codec and provides the following I/O:
3.3V GPIO with SPI port for interfacing to LCD displays.
3.3V I2C port for sensors, port expanders, etc.
5 GPIO for buttons, encoders, etc.
2 GPIO for trigger/gate I/O
4 3.3V analog CV inputs (muxed on-board to a single ADC input)
Codec level stereo in and out (needs external DC block or offset nulling).
Designed on a 4-layer process compatible w/ OSHpark. Hoping to get it fabbed over the next few weeks and build it up before the end of the month. I’ve already gotten all the Linux drivers for codec, LCD and button I/O working so (fingers crossed) it should come right up if the hardware design is not too screwed up.
Quick update on this project: I’ve gotten the PCB back from fab and built up the first one and it’s working. Assembly was no big deal - the 0.35mm pad pitch on the QFN68 had a few solder bridges but they were easy to clean up after reflow.
One minor bodge on the 3.3V power sequencing - the PWR_SEQ2 output pin goes inactive a few seconds after startup and so can’t be used to control the 3.3V power domain. I switched over to using the 1.8V rail to enable the 3.3V LDO and that seems to work. Good news is that it boots up from SD card, the 1.8V I2C bus is talking to the NAU88C22 codec, the external I2S bus is working fine and the MCLK on the AUX0 pin is generating the right frequency. Success so far - need to test the SPI LCD and encoder & button interfaces, then write some code to drive the 4-chl ADC mux I added.
More news - this week I got PCBs in for a Eurorack carrier module that hosts the CV1800B audio board. The module includes a 320x170 IPS LCD, a rotary encoder for UI navigation, signal conditioning for four channels of control voltage input (muxed into the on-chip ADC) as well as buffers & drivers for Eurorack voltage levels on the stereo audio signal. So far everything is working as planned - I just have to put the software pieces together into a usable application. That means the following:
UI elements rendered on the LCD - I believe that LVGL may be the way to go as that provides a Linux FB output method.
Integrating the CV mux & ADC triggering to continuously scan those inputs. The cv180x_saradc kernel driver is a bit cumbersome and I’m considering if that should be customized for this application.
Augmenting the device tree spec to include the ‘trigger’ button and jack, or perhaps just letting those be scanned as normal GPIO.
Porting my library of DSP effects over to Linux userspace and testing out how well they work on this CPU (fairly math intensive in some cases).
Overall happy with the progress though. No show-stoppers yet.
LCD + encoder base user interface w/ on-screen realtime displays of in/out signal levels, control voltage parameters and user-selected effects algorithm is working. It’s not “professional grade pretty”, but it works well enough for a prototype. I’ve discovered that the fbdev SPI LCD driver can really hog the CPU unless you’re careful about how the screen buffer is updated, so I’ve added some hacks to the userspace code to throttle the loading.
SAR ADC with external analog mux scanning is working as desired. The original vendor driver needed extensive modification (see thread elsewhere on this forum) but I’ve got that squared away. The overall noise on the ADC results is fairly strong and needs extensive filtering to be usable, but that’s tolerable.
Time-domain DSP effects library has been ported, providing basic delay, modulation, reverb and phasing effects. All these are working fine and don’t seem to overload the CPU.
I’ve attempted to port my frequency-domain effects but have run into the limits of the CV1800B device. These algorithms require forward and reverse 4096-point FFTs and that seems to be beyond the capability of the RISC-V CPU while running Linux. Running just the two transforms pushes total CPU load to over 60% on ‘top’ and at that point I start getting I/O errors due to scheduling of the I2S drivers. Note that these algorithms run just fine on a 480MHz STM32H7, but that’s a bare-metal system with very few background tasks running. It may be possible to do some optimization on the FFTs - I’m using ‘pffft’ which is compiled without use of the RISC-V vector extensions but with vectors it might be possible to reduce the loading by about 30-40%. That will require further research.
So TL;DR - Everything works except FFT effects. I’m a bit disappointed by that, but also not completely surprised. There are further avenues to explore, but I’d like to look at some other projects now - I’ve been working on this one for a few months now to the exclusion of other stuff.
The README includes a quick summary of everything I’ve learned in the process, including the various kernel modifications I made, Device Tree changes, and the performance I’ve seen from the full system. Hopefully this is useful and/or interesting.
Quick update - I’ve gotten the FFT-based effects working. The key was in setting the scheduling priority for my audio thread high enough that it’s not blocked by the other things going on in my system (LCD refresh, ADC sampling, encoder/button, etc). I’ve got phase vocoder effects with CPU loads in excess of 50% that have run for hours without the I/O errors I’d been seeing. Based on this I’m hopeful that I can push further with even more complex algorithms.
