yeah, I understand that all this work is done by amazingly talented volunteers and there are a ton of priorities. It looks like the long-awaited native USB support might need a little more work, given that you can completely lock up a process that opens the Pi as a USB device, presumably because the various states that the Pi goes through as a device aren't the same (yet) as a more normal external USB device. I'm not sure yet what exactly is going on and I was planning to set up event tracing to try and determine exactly why Reaper gets so thoroughly wedged up that Windows can't even shut down.
It's clearly a driver state that even the Windows kernel isn't prepared for, hence, on shutdown, I'm guessing even a CLOSE operation just blocks, possibly on an internal Windows synchronisation object or something. But for this to be actually useful in a project, it does have to be fairly robust.
In the interim the solution I had hoped to come up with, where rtpMIDI runs on core 1, as it is a time-critical task, and the remaining peripherals (touch screen, OLED display, encoder and SD card reader) can then be handled with async IO on core 0 - is a non-starter due to the issues with core 1
And I surmise these might be associated with the binary blob of firmware for the wireless side of things and hence not necessarily easy to resolve either. It's a shame because the hardware side of my project works perfectly but it looks like I picked a hardware platform that maybe wasn't the best choice. I could try the ESP32, but the ADC is pretty terrible and I'm right at the resolution limits for the touch screen now - it's completely reliable on the RPi but the ESP32 ADC non-linearity etc. is significantly worse and I'm not confident about it. And in any case I'm not sure if I'm going to have similar issues with WLAN etc anyway.
Or I could pretend the RP2040 doesn't have two cores and just do everything async. This feels very wrong though and I suspect random jitter on wireless MIDI will be the result. Ah well. I'll have a closer look at the USB issues and see if I can figure out what's going wrong there, anyway.
It's clearly a driver state that even the Windows kernel isn't prepared for, hence, on shutdown, I'm guessing even a CLOSE operation just blocks, possibly on an internal Windows synchronisation object or something. But for this to be actually useful in a project, it does have to be fairly robust.
In the interim the solution I had hoped to come up with, where rtpMIDI runs on core 1, as it is a time-critical task, and the remaining peripherals (touch screen, OLED display, encoder and SD card reader) can then be handled with async IO on core 0 - is a non-starter due to the issues with core 1
And I surmise these might be associated with the binary blob of firmware for the wireless side of things and hence not necessarily easy to resolve either. It's a shame because the hardware side of my project works perfectly but it looks like I picked a hardware platform that maybe wasn't the best choice. I could try the ESP32, but the ADC is pretty terrible and I'm right at the resolution limits for the touch screen now - it's completely reliable on the RPi but the ESP32 ADC non-linearity etc. is significantly worse and I'm not confident about it. And in any case I'm not sure if I'm going to have similar issues with WLAN etc anyway.
Or I could pretend the RP2040 doesn't have two cores and just do everything async. This feels very wrong though and I suspect random jitter on wireless MIDI will be the result. Ah well. I'll have a closer look at the USB issues and see if I can figure out what's going wrong there, anyway.
Statistics: Posted by ajay_m — Mon Jun 24, 2024 9:01 am