A trick I often used was writing to the volatile (!) CS pin control
register twice (or more).
The extra writes change nothing, but provide the tiny delay.
The compilers never optimized the extra writes away.
An obj file dumper and scope are handy to check the actual generated
code and delay.
Arie
On 2021-03-24 18:08, Grr wrote:
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
