Thank you Gregory for your reply. I will definitely examine all the links
that you provided.
I'm familiar with ARM address access limitations and also with more exotic
ARC architecture where I first met .sdata and .sbss sections usage for data
that are located near GP. But as you already pointed ou
These are pretty standard C compiler concepts, although people used to
> working with pure 32-/64-bit CPUs may not have experience with them. They
> used to be very standard like in x86 real mode.
>
>
ARM does not have near and far qualifier, but it does have some similar
memory-related issues. T
These are pretty standard C compiler concepts, although people used to
working with pure 32-/64-bit CPUs may not have experience with them. They
used to be very standard like in x86 real mode.
Since they are standard concepts, you can probably get the more
authoritative information by Googling, l
Hi,
I want to improve my knowledge about FAR usage in NuttX code. I've already
read some initial information related to "Far memory" and "3-byte pointers
to access extended memory spaces", but still lacking a practical experience
with a real compiler and device use case. My main question is about
Zou,
just a think that passed on my mind:
try to enable the CONFIG_PRIORITY_INHERITANCE and let us know if the
issue will happen again in this case.
BR,
Alan
On 3/27/22, Alan Carvalho de Assis wrote:
> Hi Zou,
>
> Is there some way to identify that thread A didn't wake up and create
> some un
Hi Zou,
Is there some way to identify that thread A didn't wake up and create
some unity test to report and to analyze it?
Maybe there is some very specific race condition that we never saw before.
BR,
Alan
On 3/27/22, fft wrote:
> Hi team,
>
>
> I've been puzzled by a strange problem for a l
Hello team,
Recently I've been reviewing "strftime()" implementation from
"libs/libc/time/lib_strftime.c" and found interesting lines:
/* %s: The number of seconds since the Epoch, that is,
* since 1970-01-01 00:00:00 UTC.
* Hmmm... mktime argume is not 'const'.
