apache
[HELP] Use cases for different sleep/delay functions
Description
I am hoping to get some clarification on when it is appropriate to use each of the sleep/delay functions provided in NuttX.
up_delay,up_udelayandup_mdelaynxsig_sleep,nxsig_usleep
If my understanding is correct, the up_xdelay functions are blocking and won't release the task during long blocks whereas the nxsig_sleep functions will release control so other tasks can run. I guess I am struggling to find a situation in which up_delay or up_mdelay should be used instead of nxsig_usleep in arch peripheral drivers. Are there side effects of nxsig_ sleeps that I am missing?
Background for why I am asking this question: The STM32 ethernet drivers use both nxsig_usleep and up_udelay/up_mdelay. In one of our H7 applications, the blocking delays (up_mdelay) in stm32_phyinit has caused issues. While I work on adding STM32H5 peripheral drivers, I want to make sure I am using the correct functions for sleep/delays.
Verification
- [x] I have verified before submitting the report.
nxsig_ can't be used at early system boot, when OS components are not yet initialized. Also blocking delays are more precise than nxsig_ if your CONFIG_BOARD_LOOPSPERMSEC is calibrated correctly. The accuracy of nxsig_ depends on the system clock tick length of your system, which in turn depends on the configuration. Additionally, with nxsig_ some time is wasted on the context switch.
If you need precise delay in the microsecond range, a blocking delay is the best option. If you don't care about precision, your delay is high or you wait for some event in loop but it's not any critical event (like ETH link status change) - you can use nxsig_.
Background for why I am asking this question: The STM32 ethernet drivers use both nxsig_usleep and up_udelay/up_mdelay. In one of our H7 applications, the blocking delays (up_mdelay) in stm32_phyinit has caused issues. While I work on adding STM32H5 peripheral drivers, I want to make sure I am using the correct functions for sleep/delays.
Is your CONFIG_BOARD_LOOPSPERMSEC correctly configured? This value may depend on the optimization level set in the configuration.
Another thing is that the delay value may be too small, causing incompatibility with the chip specification or some hardware bugs.
@raiden00pl Thanks for the detailed clarification! Glad to have a better understanding so I can use the correct ones while developing drivers.
I believe CONFIG_BOARD_LOOPSPERMSEC is configured correctly, but I can check. The ethernet driver has a 1 second blocking delay at the end of stm32_phyinit, which is the behavior we were seeing but was not compatible for our application so we have a branch with the up_mdelay replaced with a nxsig_ version.