Hardware design:
Our design implements a fairly simple digital signal processing architecture. Centered around the RP2040 Microprocessor as our CPU, two analog to digital converters (ADCs) and one digital to analog converter (DAC) allow for interaction between the front panel analog components and the CPU. This relationship is shown in the hardware block diagram shown below.
Expanding on some functional blocks, we simulated our op amp circuits using PSPICE. Building upon our own designs as well as examples provided by manufacturers, we worked to build a complete schematic.
Using Altium CircuitMaker, we developed printed circuit board designs to implement our schematics.
Our working documents can be found in our Altium Project, linked below. https://365.altium.com/designs/shared/C46C78ED-584C-4270-BDCB-77221CCF51DE
Taking advantage of JLBPCB and Digikey for PCB manufacturing and part sourcing, we were able to implement our PCB design with high quality and accuracy.
Finally we performed various tests on our hardware design, verifying its correctness for the desired application before beginning to develop firmware applications via Arduino IDE.
Firmware design:
We explored many multiprocessing frameworks in an attempt to increase sampling rate, including DMA. Ultimately we decided to utilize the two cores of the RP2040, with one core dedicated to SPI communications and the other for computation and signal processing. Utilizing both cores of the processor proved to be a relatively simple task. In firmware, we are able to configure a single function to be run on the other core. We decided that the second core would be responsible for the SPI transactions and loading the values to and from memory. A syncing variable is used to communicate to either core that the most recent values are loaded into our buffered input array. Due to the independent nature of the cores, we found that setting and checking this sync variable was not deterministic. This is caused when the sync variable is changed between the call to the variable by a polling loop and the actual access of that variable. To ensure accesses to the variable are mutually exclusive between the two cores, we utilized a mutex (mutual exclusion) lock on the syncing variable. The SPI transaction core processes interactions as follows: put read ADC values into first buffered array, indicate update of array, relocate data into second buffer, and output data from output buffer to the DAC. We utilized the buffered input array in order to allow the DSP core to process the previous ADC samples whilst the new sample is being taken. A diagram of the FSM employed can be seen below, along with a functional block diagram:
Example Firmwares:
To demonstrate the functionality of our hardware, we chose 5 demonstration firmwares, described below. Each are common modules in modular synthesis.
Voltage Controller Oscillator (VCO)
This module configuration alters its output frequency based on the voltage it sees on its input, which is essentially the audio equivalent of frequency modulation:
Voltage Controlled Amplifier (VCA)
This module configuration alters the amplitude of an input waveform based on a control voltage, which is essentially the audio equivalent of amplitude modulation:
This module configuration allows a user to connect and mix different inputs and outputs together, allowing users to reconfigure their audio connections without having to plug and unplug each channel.
This module configuration allows a user to add a delay to an audio input. This delay can be controlled by either the potentiometers on the device, or by a control voltage at an input.
This module configuration takes an input waveform then applies 8 bandpass IIR filters to it, with each band being different parts of the frequency spectrum. The attenuation of each band will be determined by the positions of the potentiometers of the module, meaning a user will be able to twist the potentiometers to attenuate each band on the fly.