It has always been the policy to disable debug features in all shipped
configurations. They were considered production configurations not
debug configurations.
Configurations that have debug enable could, perhaps, be named like
nsh-debug.
On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote:
:acas...@gmail.com]
Sent: Monday, November 23, 2020 5:09 AM
To: dev@nuttx.apache.org
Subject: Re: Should TASK_NAME_SIZE be changed in most configs?
Yes, I think nsh-debug will make its intention clear.
On 11/23/20, Gregory Nutt wrote:
It has always been the policy to disable debug features i
https://hackaday.com/2020/11/22/espressif-leaks-esp32-c3-a-wifi-soc-thats-risc-v-and-is-esp8266-pin-compatible/
https://www.cnx-software.com/2020/11/22/esp32-c3-wifi-ble-risc-v-processor-is-pin-to-pin-compatible-with-esp8266/
You can try the section on hardfault debugging here:
https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf That
starts at slide 17:
/Set a breakpoint on up_hardfault and up_assert//Set the PC equal to
the LR//Select assembly single step//And step to bx lr instruction
in d
As far as I can tell, this looks like an I2C problem. Alan problem
knows better than I.
I think the failure sequence is:
fs/vfs:
ioctl(FBIO_UPDATE)
drivers/video/fb.c ioctl method:
ret = fb->vtable->updatearea(fb->vtable, area);
drivers/lcd/lcd_framebuffer.c, functio
out"
Which is also reported by as an I2C failure by stm32_i2c_transfer():
if (stm32_i2c_sem_waitdone(priv) < 0)
{
status = stm32_i2c_getstatus(priv);
ret = -ETIMEDOUT;
On 12/4/2020 6:19 PM, Gregory Nutt wrote:
As far as I can tell, this looks like an I2C
I think the issue is that you need to halt execution right before all registers
are touched in the handler.
The problem I always found is that at this point it doesn't mean execution
arrived there due to a hardfault
as this is also used for context switches (so placing a breakpoint there is o
Several other PRs specifically removed support for fclose (stdin). Are
you certain you want to restore it? I think this needs more analysis
and resolution with the previous changes that removed the fclose() of
stdin, stdout, and stderr.
On 12/10/2020 5:37 PM, Masayuki Ishikawa wrote:
Suzuki
at 5:05 AM Gregory Nutt wrote:
Several other PRs specifically removed support for fclose (stdin). Are
you certain you want to restore it? I think this needs more analysis
and resolution with the previous changes that removed the fclose() of
stdin, stdout, and stderr.
On 12/10/2020 5:37 PM, Masayuk
You might have to write a tiny bootloader. For example like
boards/arm/sama5d4-ek/src/at25_main.c that boots from AT35 serial FLASH
on a SAMA5D4 board.
On 12/15/2020 10:55 AM, Вадим Ястребов wrote:
Hello,
I am trying to create a bootable image using Secure Provisioning Tools by NXP to boot
from an SD card, not serial.
On Tue, Dec 15, 2020 at 11:09 AM Gregory Nutt wrote:
> You might have to write a tiny bootloader. For example like
> boards/arm/sama5d4-ek/src/at25_main.c that boots from AT35 serial FLASH
> on a SAMA5D4 board.
>
> On 12/15/2020 10:55 AM, Вадим
The version in NuttX is based off an older version of SPIFFS (before all
of the security related changes) and may have incompatibilities with the
current SPIFFS.
On 12/20/2020 11:26 PM, Takashi Yamamoto wrote:
hi,
a question: is the nuttx implementation of spiffs diverted intentionally from
o
Maybe it would be better to track upstream spiffs. I don't know whether the
spiffs implementation in NuttX requires any changes from upstream but if so
maybe they can be upstreamed as well.
Not compatible. The NuttX version was a major re-implementation with
major changes. The original worke
Maybe it would be better to track upstream spiffs. I don't know
whether the
spiffs implementation in NuttX requires any changes from upstream but
if so
maybe they can be upstreamed as well.
Not compatible. The NuttX version was a major re-implementation with
major changes. The original w
The version in NuttX is based off an older version of SPIFFS (before all
of the security related changes) and may have incompatibilities with the
current SPIFFS.
do you remember which exact version of SPIFFS it was?
You will find all of that information in fs/spiffs/README.md
The version in NuttX is based off an older version of SPIFFS (before all
of the security related changes) and may have incompatibilities with the
current SPIFFS.
do you remember which exact version of SPIFFS it was?
You will find all of that information in fs/spiffs/README.md
it seems like
Unity also uses application only interfaces such as printf() that would
be inappropriate for use within the OS.
On 12/28/2020 1:00 PM, Brennan Ashton wrote:
I don't think so any testing will be part of an application. There is
nothing in the OS that would ever make use of it directly. Even if
ec 28, 2020, 11:13 AM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:
The interface is actually configurable.
We want to use that for some unit testing for the drivers, any
alternatives?
On Mon, Dec 28, 2020, 20:05 Gregory Nutt wrote:
Unity also uses application only interfa
I just use uppercase 'X' instead.
On 12/31/2020 11:49 AM, Nathan Hartman wrote:
How do we want to handle mixed case identifiers such as LTDC_LxBFCR_BF1,
LTDC_LxBFCR_BF2, LTDC_LxCFBLR_CFBLL, LTDC_LxCFBLR_CFBP, LTDC_LxCR_CLUTEN,
LTDC_LxCR_COLKEN, LTDC_LxCR_LEN, LTDC_LxWVPCR_WVSPPOS, LTDC_LxWVPCR_W
Here is an interesting application of Spresense and NuttX: Big Cat
Brother. See https://www.wildedge.info/
Is NuttX’ buildroot been adopted into Apache along with NuttX? I looked for
it, but couldn’t find it. I have a few updates to push (gcc 8.4, 9, 10). I’d
really like to share these…
No. It can't come into the Apache repository because it is GPL (at
least not without some special considera
Currently board-specific logic supports detection of when a card is
inserted or removed via a mechanical GPIO pin on the physical SD slot.
That notification is used by the SDIO-based card driver to check for a
valid card insertion/removal.
For the case of the automounter with an SD card, the
As a quick test, I made pthread_cond_wait call to pthread_sem_take
with the last argument to true (which then use the interruptible
version) and it now cancels the wait. So it would seem that this is a
bug right?
nxsem_wait_uninterruptible() should have no effect on thread
cancellation (i.e
I'm having an issue when waiting on a pthread condition variable from
the main thread and then a signal handler runs, which should cancel
the wait since I have cancellation points enabled, however this did
not happen. While debugging I see the main thread blocked when
standing inside the sig
I'm having an issue when waiting on a pthread condition variable from
the main thread and then a signal handler runs, which should cancel
the wait since I have cancellation points enabled, however this did
not happen.
I don't understand this either. A signal will not, in general, cause a
The wait I'm referring to is the one on the semaphore underlying to the condition
variable (pthread_sem_take on cond->sem). This ends up as a call to
nxsem_wait_uninterruptible which loops on the wait to ignore EINTR errors. So I
understand that a signal would not interrupt the wait (and thu
I'm not expecting the task to be killed, but the pthread_cond_wait to return
when the process receives a signal (which I'm handling in a signal handler).
What I need is to exit the pthread_cond_wait upon reception of the signal. As I
mentioned, doing pthread_cond_signal from the handler did
pthread_cond_wait() is not supposed to return if a signal is received:
https://pubs.opengroup.org/onlinepubs/009696699/functions/pthread_cond_wait.html
EINTR is not one of the valid return values from pthread_cond_wait().
This is the specific POSIX requirement that must be followed: "If a
BTW, looking at the spec for pthread_cond_wait, there's actually no
mention about a limitation regarding using pthread_cond_signal invoked
from within a signal handler to unblock a pthread_cond_wait. However,
this does not work
either for me. If you follow the signal operation, I can see that
rk. Asynchronous signal handler can get called
between any two instructions so safe synchronization with condition
variables might be hard to implement. Use semaphores and sem_post()
instead.
-Juha
----
*From:* Gregory Nutt
*
I am thinking that there must be some race condition: When the
condition variable is created the cond->sem value will be set to
zero. While waiting for cond->sem, it will be set to -1. If you see
cond->sem equal to zero, my guess would be that the signal was
received and cond->sem was incre
The information is available in "files" in the proc/ file system.
On 1/15/2021 11:59 AM, Matias N. wrote:
Hi,
I'm wondering if the gdbinit script could be extended to read task memory usage
(as would be displayed by ps command) for each task, when using the
info_nxthreads command. It would be
I don't think that this combination will work:
CONFIG_CDCACM_CONSOLE=y
CONFIG_CONSOLE_SYSLOG=y
I think that the syslog console device would have to be available at
bootup. Normally a RAM log is is used to hold syslog data if a USB
console is used.
I might be wrong about that and this should
.
I tried to see the syslog messages on an UART port while using
nutshell on usb but it didn't work.
Best regards,
Flavio
Em dom., 17 de jan. de 2021 às 13:52, Gregory Nutt
escreveu:
I don't think that this combination will work:
CONFIG_CDCACM_CONSOLE=y
CONFIG_CONSOLE_SYSLOG=y
I thin
The Raspberry Foundation created their own microcontroller based on
ARM Cortex M0+ with 1MB Flash and 256KB RAM.
I wonder how the performance is with two cores running from QSPI with no
instruction cache?
There is no data cache either. This could be an issue for SMP, at least
if the same
Now examples compile and work although in flashing mode with minicom in
VT102 mode
If you start mincom with -t vt100 it should force VT100 vs VT102 mode.
But I thought that VT102 was mostly compatible?
Yes, you are right. Perhaps this could be added to
https://github.com/apache/incubator-nuttx/issues/1352
That is a different issue description but might still be a good location
because both issues have the same solution. The solution to both issues
is to enhance the OS by adding a new OS fa
All global C++ objects are constructed in init task, so if these objects
call open, fopen or fstream related API, the similar issue happens too. How
can we fix this issue?
In order to do that, I think that each application task would have to
separately linked as they are with ELF modules or in
My thinking is that maybe upon setting up the first SIGEV_THREAD notification
for a task, a child thread would be created, which would act as a worker,
waiting on some semaphore for example. The bad thing is that it would linger
until task is finished (not sure even how easy would be to ensu
Perhaps you could use a pool of application threads as is done with
the kernel threads for the low-priority work queue. So you could have
a small number of threads that service all tasks. When a user-space
thread is needed, it could be removed from the pool and be assigned to
the task to r
The XC32 used to work years ago but I don't think anyone has used it in
the last 5 years or so. I would not recommend it. It is non-standard
and very likely incompatible. I would instead recommend any
mips-elf-gcc tool chain. There are several perbuilt MIPS toolchains
available. You can bu
I'm thinking again about this. Why wouldn't it be possible to make functions
using SIGEV_THREAD (such as timer_settime) create a pthread behind
the scenes (only the first time a SIGEV_THREAD is setup)? The underlying
watchdog would go to a handler that posts a semaphore/condition variable
that the
The prototype of the SIGEV_THREAD callback is |void(*)(union
sigval).|||The waiting thread would also need the union sigval data
which accompanies the signal. If you are not using a signal, then you
have to come up with some other mechanism to pass the union sigval data.
On 1/31/2021 9:34 AM,
TCM can mean ITCM or DTCM. What is true about one is probably not true
for the other.
On 1/31/2021 11:15 AM, Anthony Merlino wrote:
Hi all,
I was just reading the documentation on Confluence regarding ELF programs:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629543
He
Is this helpful?
https://cwiki.apache.org/confluence/display/NUTTX/Including+Files+in+board.h
On 2/5/2021 7:34 PM, Brennan Ashton wrote:
On Fri, Feb 5, 2021, 4:40 PM Grr wrote:
You cannot include arch specific headers in board.h like that! That will
break a lot of things.
board.h is arch
A good modular design should strive to hide information behind
interfaces and not expose that information globally. Global anything is
the path to spaghetti code:
Google for "information hiding in modular design"
* https://john.cs.olemiss.edu/~hcc/csci450/notes/ModularDesign.html
* https://e
You have to init the memory used for the stack:
Have a look in the normal tasking init , and you will see the call out to
init the stack, that you neeed to call.
arm_usestack() should be called in this case and won't that initialize
(colorize) the stack?
A new system, thought from the ground up to solve a problem, doesn't break
modularity per se
Replacing a correct, modular interface with bad non-modular interlace is
a very bad idea an in opposition to the INVIOLABLES.md that guild the
NuttX architecture:
## Modular Architecture
On 2/6/2021 9:01 AM, Grr wrote:
El sáb, 6 feb 2021 a las 8:57, Gregory Nutt ()
escribió:
A new system, thought from the ground up to solve a problem, doesn't
break
modularity per se
Replacing a correct, modular interface with bad non-modular interlace is
a very bad idea an in oppositi
On 2/6/2021 9:12 AM, Grr wrote:
It is very non-modular if it exposes internal data. Tha must be
strictly avoided and prohibited in all cases.
So you mean exposing STM32_BOARD_XTAL and STM32_SYSCLK_FREQUENCY is OK but
exposing board IO port address violates modularity
That logic escapes me
T
On 2/6/2021 9:13 AM, Fotis Panagiotopoulos wrote:
Indeed I was expecting arm_usestack() to do the colorization, but
apparently it doesn't.
That is what is confusing because it does do the coloration:
https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/common/arm_usestack.c#L153
I am using NuttX-v10.0.1.
This is fixed in 625eef20f00fbe9bdb4995ad9dfb24b71227e954, which came at a
later time.
Hmm.. I guess I still don't understand the failure. That change was:
#ifdef CONFIG_STACK_COLORATION
- if (tcb->pid != 0)
- {
- memset(tcb->stack_alloc_ptr,
> Hi all,
>
> I am thinking of using the STM32H747XI for a project I'm working on. This
> particular chip has a CortexM7 and a Cortex M4. The chips access the
same
> memory map and can access and even share the same peripherals.
>
> Part of the problem, however, is that NuttX resets many
> regi
The primary purpose of xyz_earlyserialinit() is to make the serial
console available for low level debug output before the serial driver is
initialized. That happens much later. That is helpful mostly for
debugging. Without early initialization of the serial console, there
will be no output un
As I said, the early serial initialization is needed for boot-up debug
output. Here is a little more detail:
If the serial is not initialized, then up_putc will not work. In fact,
any calls to up_putc() could hang. If the serial console is the syslog
debug channel, then up_putc is called fr
I developed the ez80 and used it in several projects. I was working on
a port when the quarantine lock-down made it impossible to get parts
here in Costa Rica, at least temporarily. I have not gotten back to
working with those ez80 boards for a variety of reasons.
I really like the ez80's..
I can't execute:
echo ":-)" > /test.txt
"nsh: echo: open failed: No such file or directory"
The root file system is not a "real" file system. It is a pseudo-file
system and you cannot create regular files there. See
https://cwiki.apache.org/confluence/display/NUTTX/Pseudo+File+System (a
You can call the PHY Ethernet ioctl() commands directly from board
specific code. Many things you can implement application can also be
implemented inside the board-specific logic -- with the caveat that you
have to use some different interfaces.
The PHY driver ioctl commands are in include/n
Board should export/expose resources in a general way so drivers can use
them in a common, transparent way. That's the point of a portable OS
If there's not a standard way in NuttX to export R/MII (I haven't looked at
it), maybe you need to create it
The PHY R/MII interface is exported via a
I suggested using file_open() and file_ioctl() in a previous email.
That is wrong. file_ioctl() cannot be used to access
socket_ioctls(). You would have to use psock_ioctl().
Because the socket interface goes though the network, there are some
hand shakes and interlocks to prevent network
I did that a long time ago. So have several others. See
$ find . -name "*qencoder*"
boards/arm/stm32/common/include/board_qencoder.h
boards/arm/stm32/common/src/stm32_qencoder.c
boards/arm/stm32l4/nucleo-l432kc/src/stm32_qencoder.c
boards/arm/stm32l4/nucleo-l476rg/src/stm32_qenco
I was in the middle of working with this with Konstantin when COVID
stopped everything.
We had just changed the crystal from 20MHz to 18MHz (as I recall) so
that the RAM could run with a single wait state. I was implementing a
bootloader that would reside on-chip. It would copy programs from
.
On 2/20/2021 2:45 PM, Gregory Nutt wrote:
I was in the middle of working with this with Konstantin w hen COVID
stopped everything.
We had just changed the crystal from 20MHz to 18MHz (as I recall) so
that the RAM could run with a single wait state. I was implementing a
bootloader that would
richt-
Van: Gregory Nutt
Verzonden: zaterdag 20 februari 2021 21:26
Aan: dev@nuttx.apache.org
Onderwerp: Re: Quadrature Encoder SNG-QPDB-002
I did that a long time ago. So have several others. See
$ find . -name "*qencoder*"
boards/arm/stm32/common/include/board_qencoder.h
Greg I was thinking about going the module route so I could use the eZ80F91
(same chip Byron is using). Sounds like I should just start getting some of
the parts together, the board cost is not too bad which is nice. I know a
few other people around who would probably also be interested even ou
* What can I do to debug early boot problems?
You can at first try enabling debug output. (make menuconfig -->
Build Setup --> Debug Options --> Enable Debug Features). You should
have some information regarding what's going on. Another option is to
enable DEBUG_SYMBOLS and debug the startup
than an app talking directly to a PHY or less?
El sáb, 20 feb 2021 a las 12:30, Gregory Nutt ()
escribió:
I suggested using file_open() and file_ioctl() in a previous email.
That is wrong. file_ioctl() cannot be used to access
socket_ioctls(). You would have to use psock_ioctl().
Because the
... Using
the pinguino toolchain, 2 LEDs now light up, and the debugger at least
thinks that we're in the up_idle function, so that looks promising.
After switching the serial console to UART2(for the explorer16), I do
now get data out of the serial port! The last message that I see is
"nx_st
On 2/21/2021 1:34 PM, Fotis Panagiotopoulos wrote:
You would not want to use the high priority work queue; that would
interfere with real time behavior. Nor would you want to use the low
priority work queue because that is used by most network drivers and so
would probably result in deadlocks.
Sun, Feb 21, 2021 at 11:18 AM Gregory Nutt wrote:
A breakpoint on up_assert should catch any early crashes as you
describe. There is a cool debug tip here if you hit the breakpoint:
*https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf*
Unfortunately that appears to be a broken
A breakpoint on up_assert should catch any early crashes as you
describe. There is a cool debug tip here if you hit the breakpoint:
*https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf*
Unfortunately that appears to be a broken link now.
Speaking of nuttx.events... Is there a
After initializing the SD card successfully, the driver will switch to
high-speed, 4-bit wide mode. It looks like this will be 20MHz in your case.
One thing you can try is reducing that frequency a bit.
On 2/27/2021 1:13 PM, Robert Middleton wrote:
Hi all,
I'm messing around with my PIC32/Ex
Disabling DMA is not a option on most Ethernet MACs.
On 3/4/2021 3:00 PM, Alan Carvalho de Assis wrote:
Hi John,
Did you try to disable DMA support to see if the issue disappear?
I think other MCUs are using DMA for Ethernet too and this issue
didn't happen. So I think disabling DMA could be a
I think this behavior is pretty clear from reading the H7 reference
manual. The H7 Ethernet MAC supports only three maximum packet size,
standard (1518 or 1522 if tagged), 2K, and Jumbo (9018 or 9022 if
tagged). The Jumbo packet selection is controlled by settings in registers.
So while 590
John, to answer your question on ethernet, 1500 is a very common MTU. For
VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on the
wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is
common. Minimum frame size with CRC is 64-bytes and zero padding is common,
The MAC in the the H7 has it's own dedicated internal DMA, so I don't
think that disabling the system-wide DMA would have any effect. I can
give it a shot anyways though and report back!
One thing I am wondering is if you have properly set up the MAC address
filtering. For TCP, each peer a
On 3/4/2021 4:59 PM, James Dougherty wrote:
Thank you, that is interesting. Doesn't it also imply is that with the
smaller MTU of 590 you'll end up having
fragmentation which will add a little bit of processing overhead? I
understand it is not that big of a deal since
fragmentation happens a l
My question for Greg was: Is there an assumption that CONFIG_NET_ETH_PKTSIZE
has to be 1514? So that ultimately a frame must be received completely into
one buffer?
Search for packet and frame in the Ethernet section of the reference
manual. The hardware will DMA up to (I think it was) 2048
*_lowsetup *function that
I've seen in many chips
is a standard deviation and it is actually playing the role of the
*xyz_earlyserialinit().*
Am I right?
Thanks too much for the detailed explanation.
Em qua., 10 de fev. de 2021 às 12:33, Gregory Nutt
escreveu:
As I said, the early s
1. tcgetsid() and tcsendbreak() interfaces are declared but never defined
in NuttX. Why?
Prototypes for those functions are required to be in termios.h whether
they are implemented or not.
https://pubs.opengroup.org/onlinepubs/7908799/xsh/termios.h.html
Of course it would be better if the
No, it seem that mksymtab forget to handle the case you described.
This was handled in the past, but I forget where the logic was. Let me
look around a bit.
... after a bit ...
Googling, I find that there was some handling in the simulator for
Cygwin. Some older tool toolchains did prepe
Which I think is insufficient. Probably some of the support was removed?
No.. It is just that there was no support for loadable modules for those
older Cygwin toolchains. The underscore has not been used with Cygwin
since around 2015 so I think would be safe to just remove the
CONFIG_SIM_CYG
Of course. But it will not be easy to do if you want to watch multiple
threads. Because the hardware watchdog is very binary. If any thread
were to kick the watchdog, it will not do a reset. So if one thread is
hung, but others still run, your hardware watchdog will not do what
you want, pos
I had to change my file names, from cpp to cxx. Is it mandatory to
change the file extension to use C++?
Currently, the .cxx extension is specified in the coding standard:
*https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#cplusplus*
I had to change my file names, from cpp to cxx. Is it mandatory to
change the file extension to use C++?
No, .cxx is just the default extension. You can change the default value in
Makefile like this:
CXXEXT=.cpp
But this feature just exists in Makefile under the apps folder.
Again, the cod
Most architectures support a timer library. The _oneshot.c file
is a wrapper around the library that creates an internal one shot
driver. That oneshot does not depend on the onshot driver and can be
used anywhere in the OS architecture-specific code where you need a
oneshot. The _lowerhalf.c
ter., 16 de mar. de 2021 às 14:49, Gregory Nutt
escreveu:
Most architectures support a timer library. The _oneshot.c file
is a wrapper around the library that creates an internal one shot
driver. That oneshot does not depend on the onshot driver and can be
used anywhere in the OS architectur
I would like to ask, are there cases where the timer may not fire?
Is it guaranteed to fire, for example, if the thread is in a dead lock,
The signal will be delivered to some thread in the task group, so in
that sense it will "fire". However, it may be the case that the the
dead locked th
2. Add a procfs option to the PM driver that exposes /procfs/power/state which
can be modified from the user space as well.
Currently the procfs is read-only, but there is no reason that I can
think of that we could no extended to support writing.
... what we can
do to prevent these types of "side-effects" when people are touching the
config system.
The use of defconfig files implies that we never change default values
of configuration. If someone does change the default value of a
configuration setting, then it effects ALL configur
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 confi
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 confi
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
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 cou
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 wou
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 *
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 wo
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
ntime? That way if no application calls to
getopt() (or any other function requiring similar solution), no extra space on
TLS is used.
On Wed, Mar 24, 2021, at 12:32, Gregory Nutt wrote:
Se we can either add something special just as for errno or use
entries in that array (which would re
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
101 - 200 of 1751 matches
Mail list logo
