If you are using an ARM MCU you may find the following helpful.
You must ensure that it cannot be scheduled out in any way though...
(Directly copy-pasting from one of our HAL libraries... You will need to
fine-tune it to your needs.)
/**
* Multiplier value for the ASM delay function. The delay cycles will be
* the requested uSecs delay multiplied by this value. The ASM loop needs
* two instructions per loop, which need 2 cycles to execute (4 if branch
* predictor misses, but that would not be the case for most executions).
* Assuming a 180MHz clock we need 60 loops per microsecond.
* @note The value is verified to be accurate after oscilloscope
measurements.
*/
#define DELAY_ASM_MULTIPLIER ( 60 )
void delayASM(uint32_t us)
{
us *= DELAY_ASM_MULTIPLIER;
//This implementation is taking care of the loop in assembly
//instructions, making the result much more predictable than
//a standard for loop with "nop" instructions, and it is
//independent of the compiler, and its optimizations.
asm volatile(" mov r0, %[us] \n\t"
"1: subs r0, #1 \n\t"
" bhi 1b \n\t"
:
: [us] "r" (us)
: "r0");
}
Στις Τετ, 24 Μαρ 2021 στις 7:53 μ.μ., ο/η Grr <gebbe...@gmail.com> έγραψε:
> This is a SocketCAN driver for MCP2515 with a new SPI system that
> streamlines the select->write->read->deselect process and so exposes the
> need to guarantee hold time between read and deselect and disable time
> between deselect and next select
>
> Looking at David's code, it seems the loop is the right answer. The DWT
> cannot be used for a portable solution but maybe an inline function. Thanks
> for the idea
>
> I believe NOPs are optimized away but it seems asm("") or something close
> to that is not
>
> It would be nice to incorporate a general solution for this problem to the
> Nuttx toolbox
>
> El mié, 24 mar 2021 a las 11:24, David Sidrane (<david.sidr...@nscdg.com>)
> escribió:
>
> > What HW is this on?
> >
> > -----Original Message-----
> > From: Grr [mailto:gebbe...@gmail.com]
> > Sent: Wednesday, March 24, 2021 10:09 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: Sleep Resolution
> >
> > Thank you very much for your response
> >
> > What I'm trying to do is to generate hold and disable times for SPI CS,
> > which should be about 50 ns
> >
> > I started by an empty for loop but it seems optimization gets rid of it
> (I
> > haven't researched the issue properly). Then I thought a proper function
> > would be better but got stuck in that expression "sleep resolution"
> >
> > For that scale (10 SYSCLK cycles), a loop is probably OK but I wanted to
> > make sure there's not a more appropriate system tool
> >
> > El mié, 24 mar 2021 a las 10:46, Sara da Cunha Monteiro de Souza (<
> > saramonteirosouz...@gmail.com>) escribió:
> >
> > > Hi Grr,
> > >
> > > I have never needed to use this function neither this range (ns).
> > > But I used the usleep function which resolution is defined as
> > > CONFIG_USEC_PER_TICK.
> > > But maybe, in your case, for such range, you should consider using a
> > > hardware timer or a Timer Hook.
> > > Take a look at this wiki:
> > > https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays
> > >
> > > Sara
> > >
> > > Em qua., 24 de mar. de 2021 às 13:37, Grr <gebbe...@gmail.com>
> escreveu:
> > >
> > > > Hello to all.
> > > >
> > > > Looking for the right way to create a _very_ short delay (10-100
> ns), I
> > > > found clock_nanosleep, whose description says:
> > > >
> > > > "The suspension time caused by this function may be longer than
> > > > requested
> > > > because the argument value is rounded up to an integer multiple of
> the
> > > > sleep resolution"
> > > >
> > > > What is the sleep resolution and where/how is defined?
> > > >
> > > > TIA
> > > > Grr
> > > >
> > >
> >
>
