> 1nsec means 1GHz, it is very hard to achieve the required accuracy even > with the high end CPU. But since the standard defines nano_sleep, up_ndelay > looks not so unreasonable. >
I don't mean 1 ns I mean delays in the order of _dozens_ of ns 100 MHz (a very reasonable frequency nowadays) means 10 ns per cycle, so a standard function that eases the task of delaying a few cycles for things like hold times is a _very_ needed tool > > El mié, 24 mar 2021 a las 22:34, Xiang Xiao (<xiaoxiang781...@gmail.com > >) > > escribió: > > > > > Another way to avoid the calibration is to reuse the hardware timer in > > the > > > busy loop: > > > > > > > > > https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_alarm.c#L60-L74 > > > > > > > > > https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_timer.c#L122-L144 > > > > > > On Thu, Mar 25, 2021 at 11:42 AM Gregory Nutt <spudan...@gmail.com> > > wrote: > > > > > > > > > > > > Why not call up_udelay or up_mdelay? The arch/soc should provide a > > best > > > > > implementation for you. > > > > > > > > I was wondering that too. > > > > > > > > Also, as a side note, it is very important to calibrate the delay > loop > > > > using in those functions. If the delay loop is properly calibrated, > > > > these can be very accurate (but I suspect most people no longer > > > > calibrate the delay loop). > > > > > > > > There is an app at apps/examples/calib_udelay that can be used to do > > > that. > > > > > > > > > > > > > >
