This week+, I spent most of my time continuing to wrestle with Petalinux, this time 2018.3 which is supported for the Ultra96v2. Unfortunately, despite significant efforts (as in easily 40 hours worth of attempted builds) I was unable to successfully build a petalinux image on my system. I think the only solution is to have the right native ubuntu version as well as using an official Xilinx-supported board, such as the zedboards or ZCU series. I decided at this point to cut our losses and switch gears for the digital side of the system from the Xilinx-Zynq to a raspi+mcu approach which has a far simpler toolchain. The main reason I wanted to use the Zynq in the first place was to figure out the embedded linux build process, but without good mentorship and a working toolchain this is just infeasible in the amount of time I have on top of the rest of the system software and mechanical design.
I’ve already setup simple python scripts on the pi, verified that the display works, and begun to implement the Qt application.
The new architecture for the digital hardware has two possible approaches, depending on the balance between the MCU and Raspi as well as the comms link speed:
The simple option puts the oscillators and filter control onto the STM32, since it’s the only thing the Raspi can’t do (44kHz real-time i2s on the stm32 is simple, but not on the raspi although it is possible with certain modifications). The main issue is that filter/envelope info has to be sent repeatedly over the comms link, which limits the interpolation density for the envelopes if we’re running in real time. I estimated that with the 36 byte payload (6 voices + envelopes + amplifiers) that we’d be able to update oscillators/filters at 320Hz, which should be more than sufficient. We could easily do the firmware for this on a bare-metal stm32.
If for whatever reason we run into issues here, the next step is to move all real-time synthesis to the STM32. This adds significant complexity to the stm32 software, but prevents the need to send anything over comms in real-time.
Additionally, I obtained 2 raspberry pi 3b+ and a raspi 4 to use for the synth, as well as an stm32F4 development board with a built-in i2s dac that we can use instead of the off-system i2s dac. I’ve tested the raspi, but have not tried to get the stm32 toolchain up yet, although I’ve used them before and I’m familiar with the system.
Lastly, I designed the front panel layout for the synth, including final hole positions and silkscreen/laser etching files. Sam is in the process of finalizing the design drawings for manufacturing so there might be a few modifications, but it looks like this right now. (This is at 300dpi, so feel free to open the full image and zoom on the details.)
Next week, I’m planning on working mostly on the Qt application and getting the stm32 toolchain setup. I’ve started working on the Qt application last week, but there’s not really anything to show besides that the toolchain works and there’s placeholder gui elements and some simple frameworks for patch parameters. I don’t think we’ll have any trouble running Qt on the raspi, but I want to test that ASAP as well.