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.
A
On Thu, Mar 25, 2021 at 2:22 PM Grr wrote:
> > 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 _doze
> 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) mea
On Thu, Mar 25, 2021 at 5:25 AM Grr wrote:
> Why not use msec & usec delays?
>
> Because the need is nsec delays
>
>
Ok, I understand.
> My question is:
>
> Why not add a portable, general purpose nsec delay function to Nuttx?
>
>
1nsec means 1GHz, it is very hard to achieve the required accura
Why not use msec & usec delays?
Because the need is nsec delays
My question is:
Why not add a portable, general purpose nsec delay function to Nuttx?
El mié, 24 mar 2021 a las 22:34, Xiang Xiao ()
escribió:
> Another way to avoid the calibration is to reuse the hardware timer in the
> busy loo
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
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 (
general solution for this problem to
> the
> > Nuttx toolbox
> >
> > El mié, 24 mar 2021 a las 11:24, David Sidrane ( >)
> > escribió:
> >
> > > What HW is this on?
> > >
> > > -Original Message-
> > > From: Grr [mail
On Wed, Mar 24, 2021 at 4:49 PM Grr wrote:
>
> Since afterstart = 0, there should be no loop to optimize out except ONE
> value test
>
> One hundred cycles for that would seem excessive for me
>
> TWENTY THOUSAND CYCLES for a _zero_ loop?!?
>
> Maybe in Java
We didn't see the value of transfer->d
for(delay = 0; delay < transfer->dev->afterstart; delay++);
afterstart is loop's limit, which determines the desired delay length,
known by definition
El mié, 24 mar 2021 a las 14:57, Johnny Billquist ()
escribió:
> Well. There was nothing in there that showed me that afterstart == 0. Is
> this
Well. There was nothing in there that showed me that afterstart == 0. Is
this a known fact, or an assumption?
Johnny
On 2021-03-24 21:47, Grr wrote:
Since afterstart = 0, there should be no loop to optimize out except ONE
value test
One hundred cycles for that would seem excessive for me
T
Since afterstart = 0, there should be no loop to optimize out except ONE
value test
One hundred cycles for that would seem excessive for me
TWENTY THOUSAND CYCLES for a _zero_ loop?!?
Maybe in Java
El mié, 24 mar 2021 a las 14:30, Gregory Nutt ()
escribió:
>
> > Weird behavior:
> >
> > Simpl
Weird behavior:
Simply changing loop counter variable from uint16_t to volatile uint16_t
causes initial delay (with variable delay = 0) going from ~500 ns to ~120 us
The code is
uint16_t delay;
select_function();
for(delay = 0; delay < transfer->dev->afterstart; delay++);
Any ideas?
I ima
On Wed, Mar 24, 2021 at 3:53 PM Johnny Billquist wrote:
>
> Perfectly expected.
> With volatile, the compiler are not allowed to optimize away the memory
> accesses for updating the loop variable. So you are suddenly getting a
> lot of memory read/write cycles that probably didn't happen before.
>
Perfectly expected.
With volatile, the compiler are not allowed to optimize away the memory
accesses for updating the loop variable. So you are suddenly getting a
lot of memory read/write cycles that probably didn't happen before.
I would even have expected that prior to the volatile, that loop
Weird behavior:
Simply changing loop counter variable from uint16_t to volatile uint16_t
causes initial delay (with variable delay = 0) going from ~500 ns to ~120 us
The code is
uint16_t delay;
select_function();
for(delay = 0; delay < transfer->dev->afterstart; delay++);
Any ideas?
El mié, 2
Is the Tickless mode considered stable enough for production use now?
IIRC it had some caveats when I last looked into it and I haven't had
a chance to study it again.
I believe so. I am not aware of any issues. It has been around for
several years and has been used by a lot of NuttX users.
On Wed, Mar 24, 2021 at 2:53 PM Gregory Nutt wrote:
>
>
> > The way the logic in clock_nanosleep() is written, the minimum delay
> > ends up being 2 such ticks. I don't remember why and I can't seem to
> > find it in the code right now, but I know this because I checked into
> > it recently and fo
The way the logic in clock_nanosleep() is written, the minimum delay
ends up being 2 such ticks. I don't remember why and I can't seem to
find it in the code right now, but I know this because I checked into
it recently and found out that that's how it works.
See https://cwiki.apache.org/conf
On Wed, Mar 24, 2021 at 12:37 PM Grr wrote:
> 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 inte
What I'm trying to do is to generate hold and disable times for SPI CS,
which should be about 50 ns
That resolution is too high for any system timer.
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 func
.
David
-Original Message-
From: Grr [mailto:gebbe...@gmail.com]
Sent: Wednesday, March 24, 2021 10:52 AM
To: dev@nuttx.apache.org
Subject: Re: Sleep Resolution
This is a SocketCAN driver for MCP2515 with a new SPI system that
streamlines the select->write->read->deselect proce
1 a las 11:24, David Sidrane ()
> 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
> &g
uttx toolbox
El mié, 24 mar 2021 a las 11:24, David Sidrane ()
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
>
>
, 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
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 S
Have a look at
https://github.com/PX4/PX4-Autopilot/blob/3ef93823f4b8f870b056549d321473a02fb69b1f/platforms/nuttx/src/px4/common/srgbled/srgbled.cpp#L112-L115
-Original Message-
From: Grr [mailto:gebbe...@gmail.com]
Sent: Wednesday, March 24, 2021 9:36 AM
To: dev@nuttx.apache.org
Subject
Hi Grr,
It is not a simple challenge even using a microcontroller running a
baremetal busy loop code, let alone using a RTOS. More info:
https://forum.allaboutcircuits.com/threads/programming-a-1-ns-delay-for-microcontroller-processor.90227/
It is better to have a dedicated hw taking care of the
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 be
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
30 matches
Mail list logo
