On 2023-09-18 15:10, Alan C. Assis wrote:
..
Did you enable CONFIG_LIBM in the menuconfig?
Normally it is enough if your arch correctly configured.
Yep. Enabled.
I added
LDLIBS += $(APPDIR)/../nuttx/libs/libm/libm.a
to the Makefile and the Scheme interpreter works -- some console
Hi Ken,
On 9/18/23, ken.dic...@whidbey.com wrote:
> On 2023-09-18 13:08, Alan C. Assis wrote:
>
>> The thumb rule when starting with NuttX is using an existent
>> configuration as base.
>
> OK.
>
>> Unfortunately the menuconfig is not prepared (better say it cannot) to
>> fix all dependencies
On 2023-09-18 13:08, Alan C. Assis wrote:
The thumb rule when starting with NuttX is using an existent
configuration as base.
OK.
Unfortunately the menuconfig is not prepared (better say it cannot) to
fix all dependencies for an driver or application (because of the
flexibility to use
AFAIK gdb/JTAG using openocd works fine.
ESP32S3 has internal USB_SERIAL_JTAG, so you don't need external hardware!
BR,
Alan
On 9/18/23, Mike Moretti wrote:
> Hi,
>
> Thanks. That worked.
>
> Sorry, I got as far as grepping for pthread_key_create, saw that it
> existed in the code, and then
Hi,
Thanks. That worked.
Sorry, I got as far as grepping for pthread_key_create, saw that it
existed in the code, and then just figured it would be easier to ask
here again, as after a month of this kind of thing, I'm pretty tired of
fighting with configuration/building/crashes in NuttX.
Hi Mike,
Let me explain the mental process I follow to fix this kind of error!
The error message in this case is very "clear"
undefined reference to `pthread_key_create'
So let see where it is defined:
$ cd nuttxspace/nuttx
$ git grep pthread_key_create
...
Unfortunately, using master seems to come with yet other problems. I'm
getting a link error:
xtensa-esp32s3-elf-ld:
nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal._ZN10__cxxabiv112_GLOBAL__N_110construct_Ev+0xc):
undefined reference to `pthread_key_create'
xtensa-esp32s3-elf-ld:
Hi Ken,
On 9/18/23, ken.dic...@whidbey.com wrote:
> On 2023-09-18 12:05, Alan C. Assis wrote:
>> Hi Ken,
>>
>> Are you enabling the same symbols as in the sim bas or bastest ?
>
> I just used menuconfig interpreters bas selection
>
> Raspian:RasPi4:~/RISCV/NuttX/nuttx >>> grep
On 2023-09-18 12:05, Alan C. Assis wrote:
Hi Ken,
Are you enabling the same symbols as in the sim bas or bastest ?
I just used menuconfig interpreters bas selection
Raspian:RasPi4:~/RISCV/NuttX/nuttx >>> grep CONFIG_INTERPRETER_BAS
.config
CONFIG_INTERPRETER_BAS_VERSION="2.4"
Using a released version is usually better, but since EPS32S3 has active
feature development using master can give you better features support. That
is obviously a tradeoff you need to make.
I'm trying to fix all the issues I meet with ESP32S3 as I'm trying to build
a product on top of it, but
Please open arch/xtensa/src/esp32/esp32_serial.c and search for
uart_register() function. Notice that it is wrapped by some #ifdef,
that need to be satisfied to that function be called.
Also if you enter inside boards/xtensa and "git grep UART1" or UART2
you will find some board configuration
Hello Mike,
Usually most of the "/dev/XXX" devices are registered at board level (in
xxx_bringup() call
https://github.com/apache/nuttx/blob/master/boards/xtensa/esp32s3/esp32s3-devkit/src/esp32s3_bringup.c
).
Enabling peripherals does not always lead to registration of "/dev/XXX"
node as drivers
Hi,
I'm using 12.2.1, the latest release. The more I work with this chip
the more I'm wondering if I'm going to have to move to using master.
I've been trying to avoid not using an actual release version of NuttX.
-m
On 9/18/2023 3:08 PM, Petro Karashchenko wrote:
Hello Mike,
Which
Hello Mike,
Which version of nuttx code are you using? Recently I was dealing with
UART1/2 on ESP32S3 and managed those to be working in
https://github.com/apache/nuttx/pull/10467
There were few issues including some clocking configuration problem as well
as wrong pin functions used for UART1.
Hi Ken,
Are you enabling the same symbols as in the sim bas or bastest ?
$ cd nuttxspace/nuttx
$ cd boards/
$ git grep "BAS=y"
sim/sim/sim/configs/bas/defconfig:CONFIG_INTERPRETERS_BAS=y
sim/sim/sim/configs/bastest/defconfig:CONFIG_INTERPRETERS_BAS=y
$ cd ..
$ ./tools/configure.sh
Hi,
I'm having trouble with NuttX on the ESP32S3 trying to get UART1
(configured on the default pins) working via /dev/ttyS1. The driver
code for esp32s3_serial.c seems to configure uart1 as /dev/ttys1 when
you enable it in the configs, however, testing via
serialblaster/serialrx (and our
Hi,
There are a bunch of configuration options for various peripherals,
uart0,1,2, i2c0,1, spi0,1... It appears that enabling say UART1 or
UART2 (and configuring their pins) doesn't actually automatically
register it as a ttyS in /devices. Is there some reason for this? Do I
have to
Ah. I tried using `make menuconfig` to build the Basic interpreter.
Raspian:RasPi4:~/RISCV/NuttX/apps >>> riscv64-linux-gnu-gcc-nm -u
bin/bas
U atan
U ceil
U cos
U exp
U floor
U fmod
Hi All;
From the discussion the reason for CONFIG_DEBUG_NOOPT to fail is
already known. Is this true?
Confused and ignorant
Bill Rees
On 9/18/2023 8:55 AM, Tiago Medicci Serrano wrote:
Hi Mike,
NuttX + Espressif's SoCs are intended to be built with optimization
enabled. Otherwise,
On Mon, Sep 18, 2023 at 12:07 PM Mike Moretti
wrote:
> This is the kind of thing that really should be documented somewhere.
> In bold, "DO NOT TURN OFF OPTIMIZATION because...". Either that or
> disallow it being changed, or make FULLOPT the default for every platform?
Sometimes you really
Hi Mike,
Yes, I just noticed this option in the Kconfig:
choice
prompt "Optimization Level"
default DEBUG_NOOPT if DEBUG_SYMBOLS
default DEBUG_FULLOPT if !DEBUG_SYMBOLS
Probably this is from the days when GCC for ARM and other chips didn't
work well with debug enable and
Hi Mike;
I haven't seen any screen dump of the error message(s). Are there any logs?
Bill
On 9/18/2023 9:04 AM, Mike Moretti wrote:
This is the kind of thing that really should be documented somewhere.
In bold, "DO NOT TURN OFF OPTIMIZATION because...". Either that or
disallow it being
This is the kind of thing that really should be documented somewhere.
In bold, "DO NOT TURN OFF OPTIMIZATION because...". Either that or
disallow it being changed, or make FULLOPT the default for every platform?
I only stumbled upon this because I missed copying one single config
line (the
Hi Mike,
NuttX + Espressif's SoCs are intended to be built with optimization
enabled. Otherwise, few practical applications would be possible and you'd
need to reconsider stack sizes, for instance. So, please don't disable
optimization while building practical applications.
Usually, it isn't
Hi Wang Bowen and Marten,
Is it possible to include an ostest with this code to avoid similar
regression in the future?
BR,
Alan
On 9/18/23, 汪博文 wrote:
> Hi,
>
> I did the epoll optimization last year. And your analysis is right. The new
> epoll implementation has BUG and I has reproduced
Hi Mike,
I remember facing similar issue with ESP32 in the past.
Because I started using NuttX with ARM chip and in the past the GCC
toolchain has some issue with you are trying to compile debug symbols
(-g) and optimization enabled (-O2) I always disabled optimization
while enabling debugging.
Hi,
I did the epoll optimization last year. And your analysis is right. The new
epoll implementation has BUG and I has reproduced this issue locally based on
your description.
I’m very sorry that this issue has affected your nuttx upgrade. I will fix this
issue as soon as possible. Thanks.
Hi,
I'm using NuttX 12.2.1 with ESP32S3 and have been trying for days to
figure out why it crashes on boot with our custom board/app. It turns
out that turning off CONFIG_DEBUG_FULLOPT and turning on
CONFIG_DEBUG_NOOPT is what's causing my issue (via menuconfig). The
default from all the
As I am building on aarch64/arm64 Linux, someone might have a better
time with x86.
I made a git repo:
https://github.com/KenDickey/nuttx-umb-scheme
This goes into apps/interpreters.
The code has been reliably ported a lot and should run on most targets
with command line console.
Hi Mike,
We have plans to make a simpler bootloader for the devices. For now, I
think it'd be better to document on one of the devices (ESP32, for
instance) and link that page on the others SoCs.
Once again, thank you for your contribution ;)
Best regards,
Em dom., 17 de set. de 2023 às 09:54,
Hi,
Our software heavily relies on epoll based wait/event loops, using mixes of
"real" FDs (mostly sockets), eventfd and timerfds, and after upgrading to Nuttx
12.2.1 I have some oddities in behaviour that I think can be traced to the
optimizations in
31 matches
Mail list logo
