A local maker faire happened recently (ish), which applied some time-pressure and made me reevaluate the project priorities. I easily spend a lot of time in the weeds of some random feature or refactoring code, having a temporary deadline was a nice change of perspective. Going forward I will focus on getting the MIDI 2.0 features working, so a lot of features will get put into "future work".

The EEPROM storage is now implemented on the CV module. The formatting is a bit naive, so we could probably save space by saving the configurations of outputs separate from the complete config. However, that would require a better user interface or an improved menu structure. Maybe I'll think of something in the future. A random/white noise output mode was also added, as well as pulse width for the square output. This is probably good enough for a prototype.

I have a couple of MIDI controllers which don't work with the USB module host mode, so I have been looking for bugs in the tinyusb library. Most of the bugs I've found already have open pull-requests, but I found one new bug:
Some MIDI controllers fail enumeration because their descriptors report a wrong total length, so tinyusb tries reading past the buffered values and panics. I have made a fix for this, so I will probably make a pull-request. Another bug is that the device stack runs out of RAM when using USB Audio because some functionality in the library was not implemented for the RP2040. There is an active merge request for this so it should be fixed soon.

The USB ID pin is supposed to detect the connection type so the module can know which mode it should be in, but it was giving me a lot of trouble. It somehow stopped working when the RP2040 entered device mode, which is strange because this pin is controlled by an external chip which should not be affected by the software, only the CC pins of the USB port should affect this.
In the end I found a workaround by disconnecting and reconnecting the USB line pullups in 1 second intervals while the device is not mounted. So the mode switching is finally working.

While implementing the I2S I found that getting nice audio streaming is more difficult with windows, while on linux it just worked. It seems like windows does not handle half the frames being empty, and the endpoint is probably not big enough for two millisecond of audio. In that case we would get gaps in the audio stream. This was fixed on the device by using a smaller sample buffer. Thus, audio streaming is working with the RP2040 as well.

Currently the CAN frame can contain multiple messages of the same type to reduce the overhead a bit. However, turns out this is pretty annoying to implement, at least if we ensure the order of the messages stays the same. Perhaps it would be better if it was based on the MIDI group of the messages, then it would matter less if the messages were rearranged since they would go to different endpoints and the benefits should be more consistent.

With that, it is finally time for the MIDI 2.0 features. I will consider this project done when the MIDI 2.0 function blocks are implemented, and I will try to add property exchange so parameters can be edited over MIDI. The first step is to implement the MIDI 2.0 handshake for device mode of the USB module.