Closed DonBrus closed 1 year ago
Hello @DonBrus
Thank you for your contribution. Actually, the point you raised has already been dealt and fixed internally. The fix will be made available in the frame of a future release.
We cannot share a date for the moment. So, stay tuned and thank you once more for your contribution and for your patience.
With regards
Describe the set-up
Describe the bug
Additional delays are inserted in some of the DAC HAL functions, which make use of
HAL_Delay
timebase function, whose purpose is supposedly avoiding fast switching of the DAC peripheral state, thus enforcing a minimum delay between various operations. Not only can this become cumbersome by itself, as the delay (1ms) can be considered quite large in some applications, but the biggest issue at hand is that, should the HAL timebase be temporarily suspended, i.e. because the corresponding timer is paused or the ticker ISR is not called, these functions will completely block the processor in an infinite loop.Affected functions are:
How to reproduce the bug (skip if none)
HAL_IncTick
on a periodic fashion), orAdditional context
It would be sufficient to remove these
HAL_Delay
functions inside the DAC HAL. This would also remove the cumbersome 1ms delay which is in most cases unneeded. It should also be noted that this driver is one of the very few introducing these delays, the other being the USB driver and the OPAMP driver.Another possibility would be adding a toggle variable in the DAC HAL that conditionally calls these delays when enabled.
At the current state, if maintaining the current HAL version in your own project the solution is simply copy-pasting these functions in equivalent ones without the HAL Delay call, which is not an insignificant annoyance