Since libDaisy accesses the underlying ST HAL I’m wondering how the priorities of callbacks are configured. Jobs like ADC-sampling feature default callbacks in the ST HAL and I’m guessing that the callback registration functions by libDaisy access these. They are usually configured as interrupts as far as I know, and these have priorities in the NVIC.
libDaisy seems to handle callback registrations the same way for both sampling in regular time intervals and async events like incoming messages from a host in case the Seed acts as USB CDC device. While I understand and appreciate the simplicity, I wonder why callback functions generally look like
<peripheral>.setCallback(function_pointer, data_pointer)
instead of
<peripheral>.setCallback(function_pointer, data_pointer, priority)
This way, all sorts of “stalling” issues could be easily avoided by the user, at least as far as I understand. Is there a function in the middleware or HAL that lets the user set the priority for the interrupt associated with the corresponding callback trigger? Maybe relevance is best explained by an example:
The Seed acts as a continuous audio sampler and filter for an arbitrary effect/instrument/whatever. It also acts as a USB CDC device which can be plugged into a host machine, where presets can be uploaded. In such a case, incoming data triggers the callback given in seed.usb_handle.SetReceiveCallback() (an aperiodic event unlike sampling of audio). If the cost of processing is high, the USB CDC callback is never triggered, because the audio/processing callback starves everything else. In a case with priorities, the USB CDC callback would get a higher one, instantly disabling the audio callback.
Any suggestions on this?