raiden00pl commented on issue #16259:
URL: https://github.com/apache/nuttx/issues/16259#issuecomment-2834150263
`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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
