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
Why not call up_udelay or up_mdelay? The arch/soc should provide a best
implementation for you.
On Thu, Mar 25, 2021 at 2:00 AM Fotis Panagiotopoulos
wrote:
> 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...
>
What I'm thinking is that, besides the TLS based solution, adding a
non-standard getopt() seems to be a good option anyway, since it is a
lightweight solution to this particular function.
Why do you think TLS is not lightweight. It is very lightweight. The
non-standard, non-portable
What I'm thinking is that, besides the TLS based solution, adding a
non-standard getopt() seems to be a good option anyway, since it is a
lightweight solution to this particular function.
Why do you think TLS is not lightweight. It is very lightweight. The
non-standard, non-portable
What I'm thinking is that, besides the TLS based solution, adding a
non-standard getopt() seems to be a good option anyway, since it is a
lightweight solution to this particular function.
Why do you think TLS is not lightweight. It is very lightweight. The
non-standard, non-portable
Thanks for all answers. I don't entirely understand most of them though as I'm
not really familiar with the implications of TLS or how to use it correctly.
Also, do we need per-thread or per-task data here?
You would expect getopt() to be used only on the many thread since that
is the only
On Wed, Mar 24, 2021, at 19:27, Byron Ellacott wrote:
> Here's what I found in libc that would need task (thread) specific data:
>
> - libs/libc/misc/lib_umask.c has g_mask
> - libs/libc/libgen/lib_dirname.c and libs/libc/libgen/lib_basename each
> have a g_retchar
> -
On Thu, Mar 25, 2021 at 8:27 AM Byron Ellacott
wrote:
> Hi,
>
> Since the basic problem is that `getopt` doesn't have a per-task value it
> can use, how would it keep track of which TLS key it's been allocated?
>
This question, at least, I understand the answer to having looked at the PR
- the
Hi,
Since the basic problem is that `getopt` doesn't have a per-task value it
can use, how would it keep track of which TLS key it's been allocated?
Here's what I found in libc that would need task (thread) specific data:
- libs/libc/misc/lib_umask.c has g_mask
-
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
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
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:
> >
> >
Not entirely sure about your scenario here, but if the dongle simply expects
HCI communication and you manage
to get a /dev/ttyUSB0 or whatever on NuttX side, then you should be able to use
the bt_uart bridge to expose the controller
to NuttX. From then on, you can choose to use NuttX host layer
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
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.
Am 24.03.2021 um 18:34 schrieb Tim:
I can also build in Bluetooth support and the demo app, but as far as I can
tell there are no actual Bluetooth host drivers in NuttX to properly support
a detected Bluetooth device. My custom board actually has a SiLabs Bluetooth
module on it (connected to
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é,
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
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
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
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
I asked about HW because some of the new SPI controller IP have the delays
programmable in HW. One from CS active to clock/data and the other is inter
data delays.
Using HW SS and the timers it is built in.
The issue is on a shared bus. We would need to extend the SPI API to support
the
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
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
I hope this is not too much if a newbie/dumb question as I have tried to
research this first.
I've been playing with Nuttx on a SAMA5D2-XULT board ahead of porting to my
custom board (SAMA5D27C-5M, actually), especially in regard to USB Host
functionality as that's what's drawn me to NuttX in
How about adding a few nops with the interrupts disabled?
A context switch would take longer than this delay.
On Wed, Mar 24, 2021, 14:24 David Sidrane wrote:
> What HW is this on?
>
> -Original Message-
> From: Grr [mailto:gebbe...@gmail.com]
> Sent: Wednesday, March 24, 2021 10:09 AM
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,
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
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
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
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:
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"
Great, thanks!
I was just writing an issue to have this noted somewhere.
Best,
Matias
On Wed, Mar 24, 2021, at 13:23, Gregory Nutt wrote:
> I think it is not very much work to implement. Perhaps I will submit a
> draft PR for your review.
>
>
> On 3/24/2021 9:34 AM, Matias N. wrote:
> > Yes,
I think it is not very much work to implement. Perhaps I will submit a
draft PR for your review.
On 3/24/2021 9:34 AM, Matias N. wrote:
Yes, you're right, TLS is the way to go.
I only wonder how to minimize the impact. Could this array inside the TLS
struct be grown as needed during
Yes, you're right, TLS is the way to go.
I only wonder how to minimize the impact. Could this array inside the TLS
struct be grown as needed during runtime? That way if no application calls to
getopt() (or any other function requiring similar solution), no extra space on
TLS is used.
On Wed,
Se we can either add something special just as for errno or use
entries in that array (which would require establishing a minimum
number of entries to satisfy the case of getopt en potentially
others). I think it is better to somehow "reserve" space for the
known required cases.
What
Se we can either add something special just as for errno or use entries in that array
(which would require establishing a minimum number of entries to satisfy the case of
getopt en potentially others). I think it is better to somehow "reserve" space
for the known required cases.
What i'm
Se we can either add something special just as for errno or use entries in that
array (which would require establishing a minimum number of entries to satisfy
the case of getopt en potentially others). I think it is better to somehow
"reserve" space for the known required cases.
What i'm
On 3/24/2021 8:38 AM, Matias N. wrote:
So, if I follow correctly, we could maybe have one TLS pointer pointing to a
struct of pointers, one per each group of globals (one of this groups, would be
the set of variables used by getopt()), like:
struct task_globals_s
{
struct getopt_globals_s
So, if I follow correctly, we could maybe have one TLS pointer pointing to a
struct of pointers, one per each group of globals (one of this groups, would be
the set of variables used by getopt()), like:
struct task_globals_s
{
struct getopt_globals_s *getopt_globals;
/* ...others */
};
Of course, I would only call getopt() once. My question was if we use TLS,
would the memory use scale with the number of threads? Or would this memory for
getopt() only be allocated on getopt() calls?
Yes and yes, but the memory use might be as small as a single pointer.
Per task data
Of course, I would only call getopt() once. My question was if we use TLS,
would the memory use scale with the number of threads? Or would this memory for
getopt() only be allocated on getopt() calls?
On Wed, Mar 24, 2021, at 10:56, Gregory Nutt wrote:
>
> >> You would expect getopt() to be
You would expect getopt() to be used only on the many thread since that
is the only thread that receives argc and argv.
So if it is only used in one thread there would only be a copy of the data?
What if I spawn multiple threads and call getopt only on one?
It is hard to imagine how you
On Wed, Mar 24, 2021, at 10:37, Gregory Nutt wrote:
>
> > Thanks for all answers. I don't entirely understand most of them though as
> > I'm not really familiar with the implications of TLS or how to use it
> > correctly. Also, do we need per-thread or per-task data here?
>
> You would
Thanks for all answers. I don't entirely understand most of them though as I'm
not really familiar with the implications of TLS or how to use it correctly.
Also, do we need per-thread or per-task data here?
You would expect getopt() to be used only on the many thread since that
is the
Thanks for all answers. I don't entirely understand most of them though as I'm
not really familiar with the implications of TLS or how to use it correctly.
Also, do we need per-thread or per-task data here?
What I'm thinking is that, besides the TLS based solution, adding a
non-standard
The custom handler isn't enough here, because the real problem is we need
the global variables per task/process.
As Greg suggests, we need something like TLS but per task/process not per
thread(e.g. task_getspecific/task_setspecific).
Once the mechanism is done, getopt can be converted to
The custom handler isn't enough here, because the real problem is we need
the global variables per task/process.
As Greg suggests, we need something like TLS but per task/process not per
thread(e.g. task_getspecific/task_setspecific).
Once the mechanism is done, getopt can be converted to
> For getopt() I see there's
even no standard getopt_r(), so we would have to provide our own, which
may not
be a bad idea.
Here is the one we have been using.
https://github.com/PX4/PX4-Autopilot/commit/eab32572f42f8e3e715b952512b6f5
df9041f848
On Wed, Mar 24, 2021 at 2:08 PM Xiang Xiao
wrote:
> On Wed, Mar 24, 2021 at 9:18 AM Matias N. wrote:
>
> >
> > > > - devise a mechanism to mimic what would be done by OS in KERNEL mode
> > (add
> >
> > > some custom handler to APIs internally using globals, such as getopt,
> > that can be
> >
>
54 matches
Mail list logo
