Re: NAND Flash supported Board suggestion

[Alan C. Assis]

Thank you Greg for clarifying!

I think Xiang Xiao and guohao15 also worked with NAND recently (DHARA and
YAFFS).

Seems like dhara.c was integrated into mainline, but they didn't submit
support to YAFFS (if I remember correctly it was because YAFFS requires
license payment for commercial usage).

Best Regards,

Alan

On Sat, May 25, 2024 at 4:38 PM Gregory Nutt  wrote:

>  > Mr. Greg Nutt implemented it for Atmel about 10 years ago, but if I
>  > remember correctly, he never got it well tested because there is no
> FS for
>  > NAND on NuttX.
>
> I did test the FS's that were available and they mostly worked on these
> platforms.  I could actually run nxffs and smartfs for a long while
> before they failed. They failed because the FSs that I looked at assumed
> that you can always write a "1" to a "0". Actually, you can do that but
> this then results in ECC error. Even a single bit 1=>0 change requires a
> full  erase, re-writing the ECC, and a full sector write.
>
> As I recall, nxffs would write some single "0" bits to indicate sector
> state changes; SmartFS had a small counter that was used to manage wear
> leveling.
>
>  > I think if you decide to use an SPI NAND Flash with ECC and bad block
>  > support in HW it will be easier to test your FS, in this case even
> LittleFS
>  > could work:
>  > https://github.com/littlefs-project/littlefs/issues/11
>
> Sparing and wear-leveling would also be needed.
>
>  > But later on we will need to get ECC and bad block table support on
> NuttX
>  > to validate your FS with some native NAND Flash controller.
>
> I think that software bad block and ECC are already supported and
> verified (but it has been awhile since I used them).  Sparing, and
> wear-leveling are normally done by an FTL, but can be done by the file
> system.  Bad block detection and ECC may be done by hardware, FTL, or
> higher level software.  Then the only outstanding issues are finding
> such an FTL and a file system that does not do read-modify-write
> operations without updating the ECC.
>
> LittleFS was a candidate a few years ago and required a special FTL to
> get all of these features.  Maybe that has changed in more recent versions.

Re: NAND Flash supported Board suggestion

[Alan C. Assis]

Hi Saurav,

AFAIK, the only MCUs with NAND Flash controllers supported on NuttX are
samv3 and sama5.

Mr. Greg Nutt implemented it for Atmel about 10 years ago, but if I
remember correctly, he never got it well tested because there is no FS for
NAND on NuttX.

I think if you decide to use an SPI NAND Flash with ECC and bad block
support in HW it will be easier to test your FS, in this case even LittleFS
could work:
https://github.com/littlefs-project/littlefs/issues/11

But later on we will need to get ECC and bad block table support on NuttX
to validate your FS with some native NAND Flash controller.

Best Regards,

Alan

On Fri, May 24, 2024 at 12:09 PM Saurav Pal  wrote:

> Hi all,
>
> I'm working on creating a file system for NAND Flash for NuttX as part of
> GSoC '24. I would be thankful of any suggestions that you might have for
> the type of board that I should use and the NAND flash as well.
>
> Thank you in advance.
> Regards,
> Saurav Pal
>

Re: Help on understanding Nuttx

[Alan C. Assis]

Hi Janardhan,

Each person has a different mind set and different backgrounds, so it is
difficult to find an easy way that works for everybody.

This is why I suggest everybody starting with NuttX to create their own
public documentation (i.e. blog post), because the challenges you face,
solve and document will help others with similar mind-sets and backgrounds
as yours.

I have done it for years in my blog: https://acassis.wordpress.com/?s=nuttx
and slowly I'm submitting it to our official documentation:

https://nuttx.apache.org/docs/latest/
Sony also has a great set of tutorials and documentation:
https://developer.sony.com/spresense/development-guides/sdk_tutorials_en.html

It would be nice if they integrate it into our mainline someday.

Probably for someone coming from the baremetal area NuttX will be more
challenging than for someone coming from the Embedded Linux, but looking at
the examples as you are doing will help.

It is also important to study more about POSIX and how Unix/Linux OS kernel
are organized, it will guide you to get a better understanding of NuttX.

Best Regards,

Alan

[OT] ASF Project Spotlight: NuttX

[Alan C. Assis]

Dear NuttXers,

Apache Software Foundation is becoming 25 and they are announcing some
projects that are important to them: https://apache.org/asf25years/

They posted about the NuttX RTOS:

https://news.apache.org/foundation/entry/asf-project-spotlight-nuttx

BR,

Alan

Re: [Article] NuttX on Sophgo SG2000 RISC-V SoC (Milk-V Duo S SBC)

[Alan C. Assis]

Kudos Lup!

Fantastic work! And nice board to run NuttX

On Sat, May 18, 2024 at 7:50 PM Lee, Lup Yuen  wrote:

> Soon we’ll see many new 64-bit RISC-V SBCs based on the Sophgo SG2000
> RISC-V SoC. Will they boot NuttX? Let’s find out…
>
> (1) We boot Linux on Milk-V Duo S (with SG2000)
>
> (2) Peek inside SG2000 Linux and observe how it boots
>
> (3) Then we take NuttX for RISC-V (Ox64 BL808)
>
> (4) Tweak NuttX Kernel to boot on SG2000
>
> (5) Fix the (undocumented) Interrupt Controller
>
> (6) And Milk-V Duo S boots to a fully-functional NuttX Shell
>
> (7) Something strangely satisfying about NuttX on RISC-V… We finished the
> port in Only 10 Days 
>
> Here's how: https://lupyuen.codeberg.page/articles/sg2000.html
>
> Lup
>

Re: No output for lm3s6965-ek:qemu-protected

[Alan C. Assis]

Exactly! Since you require Cortex-M, Ethernet and QEMU.

I'm not sure if the qemu-system-arm package now has support for STM32, if
it has it is possible to use some stm32 board.

Another alternative could be RISC-V on QEMU, in case Cortex-M is not an
essential requirement.

Ah, and Xtensa (ESP32) also has support on QEMU, which is also an
alternative (since it also supports Ethernet).

Best Regards,

Alan

On Tue, May 14, 2024 at 3:01 PM Robin Randhawa 
wrote:

> Thanks Alan!
>
> Would be great to get Yamamoto-San's views.
>
> Basically I want to showcase Nuttx as a good option for misc projects and
> the situation is such that I need the following attributes:
>
> 1. Cortex-M
> 2. Ethernet
> 3. Qemu
>
> Unless I'm mistaken, lm3s6965evb was the only board that met all 3 ?
>
> Cheers,
> Robin
>
> On Tue, 14 May 2024 at 18:48, Alan C. Assis  wrote:
>
> > Hi Robin,
> >
> > Thank you very much for further investigation!
> >
> > I tried to build here and found a different issue:
> >
> > CC:  wchar/lib_mbsnrtowcs.c MODULECC: chardev.c
> > CC:  proxies/PROXY_dup2.c LD: struct_main.o
> > LD: hello.o
> > CC:  readline.c LD: task.o
> > LD: signal.o
> > MODULELD: chardev.o
> > CC:  nsh_envcmds.c LD: pthread.o
> > LD: mutex.o
> > arm-none-eabi-ld: nuttx_user.elf section `.data' will not fit in region
> > `uflash'
> > arm-none-eabi-ld: region `uflash' overflowed by 64 bytes
> > make[1]: *** [Makefile:59: nuttx_user.elf] Error 1
> > make: *** [tools/Unix.mk:535: nuttx] Error 2
> >
> > After disabling some tools (i.e. wget) I was able to compile, but faced
> > similar issue as you:
> >
> > $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> > user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23
> ,hostfwd=tcp:127.0.0.1:10021-
> > 10.0.2.15:1021
> > Timer with period zero, disabling
> > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
> >
> > R00= R01= R02= R03=
> > R04= R05= R06= R07=
> > R08= R09= R10= R11=
> > R12= R13=ffe0 R14=fff9 R15=
> > XPSR=4003 -Z-- A handler
> > FPSCR: 
> >
> > This commit was added in 2021 by Yamamoto-san, so I'm CC here, maybe we
> > could give more details or have some idea what could be the issue.
> >
> > It is important to know the root causes of the issue, it could be
> something
> > related to your toolchain as well
> >
> > Looking at boards/ I noticed that qemu-kostest and qemu-protected are the
> > only ones QEMU configs with CONFIG_BUILD_PROTECTED=y enabled.
> >
> > There are other board profiles that you can test on real boards.
> >
> > Best Regards,
> >
> > Alan
> >
> > On Tue, May 14, 2024 at 2:12 PM Robin Randhawa  >
> > wrote:
> >
> > > Hi Alan.
> > >
> > > Thanks for the response.
> > >
> > > I forgot to add that I had tried to bisect things but I didn't get very
> > > far.
> > > This could be down to something silly at my end but either I couldn't
> > get a
> > > successful build or I would hit the same situation as previously
> > indicated.
> > >
> > > I decided to poke a bit further and have some points to share in the
> hope
> > > that they help:
> > >
> > > I went back to the first commit where support for this board was added
> > like
> > > so:
> > >
> > > $ cd nuttx
> > >
> > > $ git whatchanged --pretty=oneline boards/arm/tiva/lm3s6965-ek/
> > > configs/qemu-protected/defconfig | tail -n 2
> > > 702bc95cac16fe90cfaf8abb178b0822ba707521 tiva/lm3s6965-ek: Add a few
> > > configs for qemu
> > >
> > > $ git checkout -b test 702bc95cac16fe90cfaf8abb178b0822ba707521
> > >
> > > $ ./tools/configure.sh lm3s6965-ek:qemu-protected
> > >
> > > $ make -j(nproc)
> > >
> > > .. which ended with:
> > >
> > > ===
> > > AR (create): libboard.a   lm_boot.o lm_leds.o lm_ethernet.o lm_ssi.o
> > > lm_appinit.o lm_bringup.o
> > > make[2]: Leaving directory 'nuttx_workspace/nuttx/boards/
> > > arm/tiva/lm3s6965-ek/src'
> > > LD: nuttx
> > > arm-none-eabi-ld: Error: unable to disambiguate: -nostartfiles (did you
> > > mean --nostartfiles ?)
> > > make[1]: *** [Makefile:172: nuttx] Error 1
> > > make[1]: Leaving directory 'nuttx_workspace/nuttx/arch/arm/src'
> > > ma

Re: No output for lm3s6965-ek:qemu-protected

[Alan C. Assis]

04d1 04d1 04d1
> 04d1 04d1 04d1
> up_stackdump: 00e0: 04d1 04d1 04d1 04d1 04d1
> 04d1 04d1 04d1
> up_stackdump: 0100: 04d1 04d1 04d1 04d1 04d1
> 04d1 04d1 f000b508
> up_stackdump: 0120: f000f8b1 2041fa15 fa0af000 4b172100 42934a17
> 2042d321 fa02f000 4a164b15
> up_stackdump: 0140: 428b4916 2043d31c f9faf000 fb12f000 f0002044
> f000f9f5 2045f89d f9f0f000
> up_stackdump: 0160: f970f001 f0002046 200df9eb f9e8f000 f000200a
> f001f9e5 f843f9a5 e7d81b04
>
> I took care to ensure that my apps directory was reset to a date that
> corresponded to the commit used for the nuttx directory.
>
> Interestingly - and as indicated in my first post - a build with the latest
> nuttx and apps dirs doesn't produce the above output. However, when I look
> at my poor person's 'boot log' I see the same invocation of
> irq_unexpected_isr.
>
> My theory, therefore, is that lm3s6965-ek:qemu-protected has never worked
> ever since support was committed ?
> Also: I think the unexpected IRQ 11 (that's an SVC exception I think ?) has
> been the problem since the beginning and continues to manifest even with
> the latest nuttx.
>
> I would appreciate any advice. I will try and explore a bit further myself
> but I am very new to NuttX.
>
> Cheers,
> Robin
>
> On Mon, 13 May 2024 at 22:35, Alan C. Assis  wrote:
>
> > Hi Robin,
> >
> > Did you test previous release versions? It could be useful to know in
> which
> > version the issue was introduced.
> >
> > After that we could use git bisect to pinpoint the commit that introduced
> > this issues.
> >
> > Best Regards,
> >
> > Alan
> >
> > On Mon, May 13, 2024 at 5:41 PM Robin Randhawa  >
> > wrote:
> >
> > > Hi.
> > >
> > > I find that:
> > >
> > > $ ./tools/configure.sh lm3s6965-ek:qemu-flat
> > > $ make
> > > $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> > > user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=
> > tcp:127.0.0.1:10021-
> > > 10.0.2.15:21 -kernel nuttx -nographic
> > >
> > > .. gets me to a nice NSH prompt with ping working.
> > >
> > > However, the following:
> > >
> > > $ ./tools/configure.sh lm3s6965-ek:qemu-protected
> > > $ make
> > > $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> > > user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=
> > tcp:127.0.0.1:10021-
> > > 10.0.2.15:21 -kernel nuttx -nographic
> > >
> > > .. gets me:
> > >
> > > 
> > >
> > > Timer with period zero, disabling
> > > ABCEF
> > >
> > > 
> > >
> > > .. with no other output.
> > >
> > > Adding qemu logging after disabling translation block chaining using:
> > >
> > > $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> > > user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=
> > tcp:127.0.0.1:10021-
> > > 10.0.2.15:21 -kernel nuttx -nographic -d nochain,in_asm -D
> /tmp/qemu.log
> > >
> > > .. and processing the log like so gives me (with apologies for the
> > > verbosity):
> > >
> > > $ cat /tmp/qemu.log | grep ^IN | awk '!seen[$0]++' | nl
> > > 1  IN: __start
> > > 2  IN: tiva_clock_configure
> > > 3  IN: tiva_clock_reconfigure
> > > 4  IN: tiva_lowsetup
> > > 5  IN: modifyreg32
> > > 6  IN: tiva_configgpio
> > > 7  IN: tiva_gpiobaseaddress
> > > 8  IN: tiva_gpiofunc
> > > 9  IN: tiva_gpiowrite
> > > 10  IN: arm_lowputc
> > > 11  IN: memset
> > > 12  IN: memcpy
> > > 13  IN: tiva_userspace
> > > 14  IN: tiva_mpuinitialize
> > > 15  IN: mpu_configure_region
> > > 16  IN: mpu_allocregion
> > > 17  IN: mpu_log2regionceil
> > > 18  IN: mpu_subregion
> > > 19  IN: mpu_control
> > > 20  IN: tiva_boardinitialize
> > > 21  IN: lm_ssidev_initialize
> > > 22  IN: board_autoled_initialize
> > > 23  IN: nx_start
> > > 24  IN: strlcpy
> > > 25  IN: up_allocate_heap
> > > 26  IN: mpu_log2regionfloor
> > > 27  IN: board_autoled_on
> > > 28  IN: tiva_mpu_uheap
> > > 29  IN: umm_initialize
> > > 30  IN: mm_initialize
> > > 31  IN: nxmutex_init
> > > 32  IN: nxsem_init
> > > 33  IN: nxsem_set_protocol
> > > 34  IN: mm_addregion
> > > 35  IN: mm_lock
> > &g

Re: No output for lm3s6965-ek:qemu-protected

[Alan C. Assis]

Hi Robin,

Did you test previous release versions? It could be useful to know in which
version the issue was introduced.

After that we could use git bisect to pinpoint the commit that introduced
this issues.

Best Regards,

Alan

On Mon, May 13, 2024 at 5:41 PM Robin Randhawa 
wrote:

> Hi.
>
> I find that:
>
> $ ./tools/configure.sh lm3s6965-ek:qemu-flat
> $ make
> $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-
> 10.0.2.15:21 -kernel nuttx -nographic
>
> .. gets me to a nice NSH prompt with ping working.
>
> However, the following:
>
> $ ./tools/configure.sh lm3s6965-ek:qemu-protected
> $ make
> $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-
> 10.0.2.15:21 -kernel nuttx -nographic
>
> .. gets me:
>
> 
>
> Timer with period zero, disabling
> ABCEF
>
> 
>
> .. with no other output.
>
> Adding qemu logging after disabling translation block chaining using:
>
> $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-
> 10.0.2.15:21 -kernel nuttx -nographic -d nochain,in_asm -D /tmp/qemu.log
>
> .. and processing the log like so gives me (with apologies for the
> verbosity):
>
> $ cat /tmp/qemu.log | grep ^IN | awk '!seen[$0]++' | nl
> 1  IN: __start
> 2  IN: tiva_clock_configure
> 3  IN: tiva_clock_reconfigure
> 4  IN: tiva_lowsetup
> 5  IN: modifyreg32
> 6  IN: tiva_configgpio
> 7  IN: tiva_gpiobaseaddress
> 8  IN: tiva_gpiofunc
> 9  IN: tiva_gpiowrite
> 10  IN: arm_lowputc
> 11  IN: memset
> 12  IN: memcpy
> 13  IN: tiva_userspace
> 14  IN: tiva_mpuinitialize
> 15  IN: mpu_configure_region
> 16  IN: mpu_allocregion
> 17  IN: mpu_log2regionceil
> 18  IN: mpu_subregion
> 19  IN: mpu_control
> 20  IN: tiva_boardinitialize
> 21  IN: lm_ssidev_initialize
> 22  IN: board_autoled_initialize
> 23  IN: nx_start
> 24  IN: strlcpy
> 25  IN: up_allocate_heap
> 26  IN: mpu_log2regionfloor
> 27  IN: board_autoled_on
> 28  IN: tiva_mpu_uheap
> 29  IN: umm_initialize
> 30  IN: mm_initialize
> 31  IN: nxmutex_init
> 32  IN: nxsem_init
> 33  IN: nxsem_set_protocol
> 34  IN: mm_addregion
> 35  IN: mm_lock
> 36  IN: nxsched_gettid
> 37  IN: nxmutex_lock
> 38  IN: nxsem_wait
> 39  IN: nxsched_remove_readytorun
> 40  IN: nxsched_add_prioritized
> 41  IN: up_switch_context
> 42  IN: exception_common
> 43  IN: arm_doirq
> 44  IN: arm_ack_irq
> 45  IN: irq_dispatch
> 46  IN: irq_unexpected_isr
> 47  IN: syslog
> 48  IN: vsyslog
> 49  IN: nx_vsyslog
> 50  IN: lib_syslograwstream_open
> 51  IN: lib_vsprintf_internal
> 52  IN: vsprintf_internal.constprop.0
> 53  IN: strnlen
> 54  IN: syslograwstream_puts
> 55  IN: syslog_write
> 56  IN: syslograwstream_putc
> 57  IN: syslog_putc
> 58  IN: __ultoa_invert
> 59  IN: __aeabi_uldivmod
> 60  IN: __udivmoddi4
> 61  IN: __assert
> 62  IN: _assert
> 63  IN: up_saveusercontext
> 64  IN: panic_notifier_call_chain
> 65  IN: syslog_flush
> 66  IN: uname
> 67  IN: gethostname
> 68  IN: snprintf
> 69  IN: lib_memoutstream
> 70  IN: lib_vsprintf
> 71  IN: memoutstream_puts
> 72  IN: memoutstream_putc
> 73  IN: up_dump_register
> 74  IN: up_getusrsp
> 75  IN: up_check_tcbstack
> 76  IN: arm_stack_check
> 77  IN: stack_dump
> 78  IN: nxsched_foreach
> 79  IN: sched_lock
> 80  IN: sched_unlock
> 81  IN: reboot_notifier_call_chain
> 82  IN: up_mdelay
> 83  IN: board_autoled_off
>
> I assume this is unexpected ? If not, I'd appreciate any insights.
>
> Thanks,
> Robin
>

Re: Help regarding the code formatting

[Alan C. Assis]

Hi Janardhan,

Please read the official documentation:
https://nuttx.apache.org/docs/latest/contributing/making-changes.html

There is a tool called checkpatch.sh that you can use to verify the coding
style issues in your source code.

Best Regards,

Alan

On Fri, May 3, 2024 at 4:25 AM Janardhan Silwal 
wrote:

> Hi,
>
> I am kind of getting started with NuttX and am adding minimalistic
> board/chip already not available in the NuttX repo.
>
> I would like to create a pull request and get help in evaluating the
> additions and support in debugging.
>
> I was looking through the coding standard, and I am kinda confused about
> how to properly run through the necessary checks. Is there some
> documentation regarding how to carry that out?
>
> Or is there a formatting script available which formats, at least,
> indentation, and horizontal/vertical spacing at once, which can be
> integrated into VSCode?
>
> Best Regards,
> Janardhan
>

Welcoming Saurav Pal to NuttX GSoC

[Alan C. Assis]

Hi NuttXers,

As Lup commented, we have two NuttX proposals accepted to the GSoC 2024.

Saurav Pal also was accepted and he will work in the project:

mnemofs: An Apache NuttX NAND Flash Filesystem

Basically this will be a file-system to use with NAND Flash memories,
including bad-block management and wear-leveling.

Congratulations Saurav Pal, we are glad for having you here!

Best Regards,

Alan

Re: nuttx user question

[Alan C. Assis]

Hi David,

I think we can start creating the missing functions, like
eMBMasterASCIIStart(), I think we could use eMBMasterRTUStart() as
reference.

Probably we will need to modify some timing values, since ASCII delays more
time to transmit data.

Best Regards,

Alan


On Tue, Apr 30, 2024 at 12:36 PM David Welshon 
wrote:

> Ok,
> I have the device setup. I can help test whenever needed.
> David
>
> On Wed, Apr 24, 2024 at 7:17 AM Alan C. Assis  wrote:
>
> > Hi David,
> >
> > I'm glad to help!
> >
> > More people could want this feature, so it is important to fix.
> >
> > Best Regards,
> >
> > Alan
> >
> > On Tuesday, April 23, 2024, David Welshon 
> wrote:
> >
> > > Thank you btw!
> > >
> > > On Tue, Apr 23, 2024 at 9:22 PM David Welshon  >
> > > wrote:
> > >
> > > > I can help test.  I'll have to get a device tomorrow from work first.
> > > I'll
> > > > let you know when I have it setup.
> > > >
> > > > On Tue, Apr 23, 2024 at 8:09 PM Alan C. Assis 
> > wrote:
> > > >
> > > >> David,
> > > >>
> > > >> I fixed the header, but it seems someone did a partial port of
> > > FreeModbus,
> > > >> it is missing many functions for modbus ASCII:
> > > >>
> > > >> mb_m.c: In function 'eMBMasterInit':
> > > >> mb_m.c:176:33: error: 'eMBMasterASCIIStart' undeclared (first use in
> > > this
> > > >> function); did you mean 'eMBMasterTCPInit'?
> > > >>   176 |   pvMBMasterFrameStartCur = eMBMasterASCIIStart;
> > > >>   | ^~~
> > > >>   | eMBMasterTCPInit
> > > >> mb_m.c:176:33: note: each undeclared identifier is reported only
> once
> > > for
> > > >> each function it appears in
> > > >> IN: libs/libc/libc.a -> staging/libc.a mb_m.c:177:32: error:
> > > >> 'eMBMasterASCIIStop' undeclared (first use in this function)
> > > >>   177 |   pvMBMasterFrameStopCur = eMBMasterASCIIStop;
> > > >>   |^~
> > > >> mb_m.c:178:32: error: 'eMBMasterASCIISend' undeclared (first use in
> > this
> > > >> function); did you mean 'eMBMasterClose'?
> > > >>   178 |   peMBMasterFrameSendCur = eMBMasterASCIISend;
> > > >>   |^~
> > > >>   |eMBMasterClose
> > > >> mb_m.c:179:35: error: 'eMBMasterASCIIReceive' undeclared (first use
> in
> > > >> this
> > > >> function); did you mean 'peMBMasterFrameReceiveCur'?
> > > >>   179 |   peMBMasterFrameReceiveCur = eMBMasterASCIIReceive;
> > > >>   |   ^
> > > >>   |   peMBMasterFrameReceiveCur
> > > >> mb_m.c:181:39: error: 'xMBMasterASCIIReceiveFSM' undeclared (first
> use
> > > in
> > > >> this function)
> > > >>   181 |   pxMBMasterFrameCBByteReceived =
> > xMBMasterASCIIReceiveFSM;
> > > >>   |
>  ^~~~
> > > >> mb_m.c:182:43: error: 'xMBMasterASCIITransmitFSM' undeclared (first
> > use
> > > in
> > > >> this function); did you mean 'pxMBMasterFrameCBTransmitFSMCur'?
> > > >>   182 |   pxMBMasterFrameCBTransmitterEmpty =
> > > >> xMBMasterASCIITransmitFSM;
> > > >>   |
> > > >>  ^
> > > >>   |
> > > >> pxMBMasterFrameCBTransmitFSMCur
> > > >> mb_m.c:183:38: error: 'xMBMasterASCIITimerT1SExpired' undeclared
> > (first
> > > >> use
> > > >> in this function)
> > > >>   183 |   pxMBMasterPortCBTimerExpired =
> > > >> xMBMasterASCIITimerT1SExpired;
> > > >>   |
> > > ^
> > > >> mb_m.c:185:17: warning: implicit declaration of function
> > > >> 'eMBMasterASCIIInit'; did you mean 'eMBMasterTCPInit'?
> > > >> [-Wimplicit-function-declaration]
> > > >>   185 |   eStatus = eMBMasterASCIIInit(ucPort, ulBaudRate,
> > eParity);
> > > >>   | ^~
> > > >>   | 

Re: Multiple zerocross pins

[Alan C. Assis]

Hi David,

The pin is defined as BOARD_ZEROCROSS_GPIO, please look at

nuttx/boards/arm/stm32/stm32f103-minimum/include/board.h
nuttx/boards/arm/stm32/stm32f4discovery/include/board.h

The board initialization code is here:
nuttx/boards/arm/stm32/common/src/stm32_zerocross.c

And the example is here: apps/examples/zerocross/zerocross_main.c

The old video example is here: https://www.youtube.com/watch?v=NRMnW6jKsiw

Best Regards,

Alan

On Tue, Apr 30, 2024 at 4:07 PM David Welshon 
wrote:

> Is there an example driver, that I should/could look at to add pins to the
> zerocrossdriver?
> What would be the steps involved if I wanted to add pins to an stm32f401re?
> I am currently using the stm32_zerocross in the stm32/common/src folder.
>
> but it looks like this lower half is hardcoded for 1 pin.
>
> Thanks for any pointers
>
> David
>

Re: Integrating user code into a configuration

[Alan C. Assis]

I think you can do it, but keep in mind that the idea of board profile is
to test some specific feature or a set of features.

Probably you were expecting the raspberrypi-pico-w:audiopack to include the
WiFi since the board has WiFi support, but probably for the author of the
board profile his plan was just to focus on audio features.

It is normally easy to merge two board profiles, basically you start
configuring the original board profile (that one with WiFi support), then
you create a backup of the generated .config:

$ cp .config config_raspipico_wifi

Than you make distclean and configuregure that raspberrypi-pico-w:audiopack
and create a backup of the generated .config:

$ cp .config config_raspipico_audio

Thank you compare both configs moving the audio enabled symbols to wifi
config:

$ meld config_raspipico_wifi config_raspipico_audio

This is a good experience someone working with NuttX needs to master to
speed up the development process.

Best Regards,

Alan

On Sun, Apr 28, 2024 at 4:43 PM M. Edward (Ed) Borasky
 wrote:

> Thanks! That's a big part of what I'm trying to do. Should I open an issue
> on the raspberrypi-pico-w:audiopack not having a wireless configuration
> option? As it stands now I'd have to pull in the WiFi stack from the Pico
> SDK into a custom application like I'm planning to do with TinyUSB.
>
> --
> AlgoCompSynth by znmeb https://universodon.com/@AlgoCompSynth
>
> I don't have the hand muscles for strongly-typed languages.
>
> Sent with Proton Mail secure email.
>
> On Sunday, April 28th, 2024 at 4:11 AM, Alan C. Assis 
> wrote:
>
> > Hi Ed,
> >
> > Welcome to NuttX!
> >
> > We have a documentation explaining about it, please see section 3:
> >
> > https://nuttx.apache.org/docs/latest/guides/customapps.html
> >
> > Best Regards,
> >
> > Alan
> >
>
>

Re: Integrating user code into a configuration

[Alan C. Assis]

Hi Ed,

Welcome to NuttX!

We have a documentation explaining about it, please see section 3:

https://nuttx.apache.org/docs/latest/guides/customapps.html

Best Regards,

Alan

On Sun, Apr 28, 2024 at 1:36 AM M. Edward (Ed) Borasky
 wrote:

> I've just run across NuttX, and I think it's a good fit for my project.
> What I'm trying to do is develop computer music applications on
> microcontrollers. I'm mostly interested in the Raspberry Pi Pico W, but I
> also have some ESP32 S3, ESP 32 C3/C6, and Teensy 4.1 boards and would like
> the applications to run using the "sim" board on 64-bit Linux machines as
> well.
>
> My first target is the Pimoroni PicoVision. This has a Raspberry Pi Pico W
> as the main processor and a second highly overclocked RP2040 to drive the
> HDMI signal generation. It also has an I2S audio interface driving a DAC
> and stereo output jack. I won't be using the HDMI at the beginning. If I
> can get the PicoVision working, the same code should work on any Pico W I2S
> audio implementation.
>
> The existing raspberrypi-pico-w:audiopack does much of what I want except
> for a couple of minor issues:
>
> - The configuration doesn't seem to use the wireless on the Pico W. I'd
> like to be able to access the system via wireless, for example, to
> broadcast to a Bluetooth speaker.
> - I couldn't find a library in NuttX for MIDI or audio over USB. That
> isn't critical; those exist in TinyUSB.
>
> Which brings me to my main question: how do I use NuttX as a build system
> for my own code without integrating my code into a fork of NuttX
> repositories as I would for a formal contribution to the NuttX project?
>
> It's not a licensing issue; everything I do is open source for code and
> Creative Commons for documentation. It's mainly logistics; I don't want an
> end user to have to download NuttX and learn how to add a board or an
> application in order to use my code.
>
> Getting the PicoVision audio working with raspberrypi-pico-w:audiopack
> looks easy; I think all I have to do is make sure the I2S GPIO pin numbers
> are correct in the configuration. But is there documentation on how to use
> the media player? I couldn't find any. And how do I go about adding WiFi
> and Bluetooth to the configuration? I didn't see them in the existing Pico
> W one.
>
> I guess what I'm looking for is a guide for how to compose the pieces -
> board definitions, libraries and both NuttX and my own applications code -
> into a working configuration file that I can use.
>
> --
> AlgoCompSynth by znmeb https://universodon.com/@AlgoCompSynth
>
> I don't have the hand muscles for strongly-typed languages.
>
> Sent with [Proton Mail](https://proton.me/) secure email.

Re: ESP32 (classic) RAM size question

[Alan C. Assis]

Yes, Abdelatif is right, I think only Bluetooth requires a reserved area of
the RAM.

For WiFi the driver itself on the NuttX kernel is enough.

Currently there is no support to direct boot on ESP32 (to avoid using the
bootloader), only ESP32-C3 and newer chips have support for it.

Best Regards,

Alan

On Fri, Apr 26, 2024 at 9:26 AM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> 200KB should be the remaining SRAM size.
>
> BLE uses 32KB of SRAM. I don't remember Wifi having a fixed carevout in
> SRAM. Then there are other areas used by the ROM bootloader that can be
> revoked once the system has fully booted.
>
>
> On Fri, Apr 26, 2024 at 2:22 PM Nathan Hartman 
> wrote:
>
> > I recommend to add a comment there, to explain that although the board
> has
> > 320KB in total, ~200KB is used for WiFi and BLE.
> >
> > On Thu, Apr 25, 2024 at 8:36 PM Alan C. Assis  wrote:
> >
> > > Hi Bernd,
> > >
> > > You can use 320KB only if you don't need to use WiFi and BLE.
> > >
> > > The memory is used but the WiFi/BLE driver!
> > >
> > > Do you remember the old days where your video card used to eat your
> main
> > > memory and you should define in the BIOS how much memory the video card
> > > will use?
> > >
> > > Same thing here! ;-)
> > >
> > > Best Regards,
> > >
> > > Alan
> > >
> > > On Thu, Apr 25, 2024 at 8:59 PM Bernd Walter 
> > > wrote:
> > >
> > > > The original ESP32 is said to have 320k RAM.
> > > > All board configs have the following:
> > > > CONFIG_RAM_SIZE=114688
> > > >
> > > > Are RAM sections added later in the startup process or is there
> another
> > > > reason?
> > > >
> > > > --
> > > > B.Walter  https://www.bwct.de
> > > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
> > > >
> > >
> >
>

Re: ESP32 (classic) RAM size question

[Alan C. Assis]

Hi Bernd,

You can use 320KB only if you don't need to use WiFi and BLE.

The memory is used but the WiFi/BLE driver!

Do you remember the old days where your video card used to eat your main
memory and you should define in the BIOS how much memory the video card
will use?

Same thing here! ;-)

Best Regards,

Alan

On Thu, Apr 25, 2024 at 8:59 PM Bernd Walter 
wrote:

> The original ESP32 is said to have 320k RAM.
> All board configs have the following:
> CONFIG_RAM_SIZE=114688
>
> Are RAM sections added later in the startup process or is there another
> reason?
>
> --
> B.Walter  https://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
>

Re: nuttx user question

[Alan C. Assis]

Hi David,

I'm glad to help!

More people could want this feature, so it is important to fix.

Best Regards,

Alan

On Tuesday, April 23, 2024, David Welshon  wrote:

> Thank you btw!
>
> On Tue, Apr 23, 2024 at 9:22 PM David Welshon 
> wrote:
>
> > I can help test.  I'll have to get a device tomorrow from work first.
> I'll
> > let you know when I have it setup.
> >
> > On Tue, Apr 23, 2024 at 8:09 PM Alan C. Assis  wrote:
> >
> >> David,
> >>
> >> I fixed the header, but it seems someone did a partial port of
> FreeModbus,
> >> it is missing many functions for modbus ASCII:
> >>
> >> mb_m.c: In function 'eMBMasterInit':
> >> mb_m.c:176:33: error: 'eMBMasterASCIIStart' undeclared (first use in
> this
> >> function); did you mean 'eMBMasterTCPInit'?
> >>   176 |   pvMBMasterFrameStartCur = eMBMasterASCIIStart;
> >>   | ^~~
> >>   | eMBMasterTCPInit
> >> mb_m.c:176:33: note: each undeclared identifier is reported only once
> for
> >> each function it appears in
> >> IN: libs/libc/libc.a -> staging/libc.a mb_m.c:177:32: error:
> >> 'eMBMasterASCIIStop' undeclared (first use in this function)
> >>   177 |   pvMBMasterFrameStopCur = eMBMasterASCIIStop;
> >>   |^~
> >> mb_m.c:178:32: error: 'eMBMasterASCIISend' undeclared (first use in this
> >> function); did you mean 'eMBMasterClose'?
> >>   178 |   peMBMasterFrameSendCur = eMBMasterASCIISend;
> >>   |^~
> >>   |eMBMasterClose
> >> mb_m.c:179:35: error: 'eMBMasterASCIIReceive' undeclared (first use in
> >> this
> >> function); did you mean 'peMBMasterFrameReceiveCur'?
> >>   179 |   peMBMasterFrameReceiveCur = eMBMasterASCIIReceive;
> >>   |   ^
> >>   |   peMBMasterFrameReceiveCur
> >> mb_m.c:181:39: error: 'xMBMasterASCIIReceiveFSM' undeclared (first use
> in
> >> this function)
> >>   181 |   pxMBMasterFrameCBByteReceived = xMBMasterASCIIReceiveFSM;
> >>   |   ^~~~
> >> mb_m.c:182:43: error: 'xMBMasterASCIITransmitFSM' undeclared (first use
> in
> >> this function); did you mean 'pxMBMasterFrameCBTransmitFSMCur'?
> >>   182 |   pxMBMasterFrameCBTransmitterEmpty =
> >> xMBMasterASCIITransmitFSM;
> >>   |
> >>  ^
> >>   |
> >> pxMBMasterFrameCBTransmitFSMCur
> >> mb_m.c:183:38: error: 'xMBMasterASCIITimerT1SExpired' undeclared (first
> >> use
> >> in this function)
> >>   183 |   pxMBMasterPortCBTimerExpired =
> >> xMBMasterASCIITimerT1SExpired;
> >>   |
> ^
> >> mb_m.c:185:17: warning: implicit declaration of function
> >> 'eMBMasterASCIIInit'; did you mean 'eMBMasterTCPInit'?
> >> [-Wimplicit-function-declaration]
> >>   185 |   eStatus = eMBMasterASCIIInit(ucPort, ulBaudRate, eParity);
> >>   | ^~
> >>   | eMBMasterTCPInit
> >> IN: mm/libmm.a -> staging/libmm.a make[2]: ***
> >> [/home/alan/nuttxspace/apps/Application.mk:200:
> >> mb_m.c.home.alan.nuttxspace.apps.modbus.o] Error 1
> >> make[2]: *** Waiting for unfinished jobs
> >> make[1]: *** [Makefile:51: /home/alan/nuttxspace/apps/modbus_all]
> Error 2
> >> make: *** [tools/LibTargets.mk:232: /home/alan/nuttxspace/apps/
> libapps.a]
> >> Error 2
> >>
> >> I think those functions should be copied from the original project and
> >> added.
> >>
> >> I don't have a device with Modbus ASCII to test, but if you want to help
> >> testing I can implement it.
> >>
> >> Best Regards,
> >>
> >> Alan
> >>
> >> On Tue, Apr 23, 2024 at 8:19 PM David Welshon 
> >> wrote:
> >>
> >> > now it can't find the header file it seems
> >> >
> >> > make[2]: Entering directory '/home/david/nuttxspace/apps/modbus'
> >> >
> >> > CC: mb_m.c
> >> >
> >> > arm-none-eabi-gcc -c -Wstrict-prototypes -Wno-attributes
> >> > -Wno-unknown-pragmas -Wno-psabi -Os -fno-strict-aliasing
> >&g

Re: nuttx user question

[Alan C. Assis]

David,

I fixed the header, but it seems someone did a partial port of FreeModbus,
it is missing many functions for modbus ASCII:

mb_m.c: In function 'eMBMasterInit':
mb_m.c:176:33: error: 'eMBMasterASCIIStart' undeclared (first use in this
function); did you mean 'eMBMasterTCPInit'?
  176 |   pvMBMasterFrameStartCur = eMBMasterASCIIStart;
  | ^~~
  | eMBMasterTCPInit
mb_m.c:176:33: note: each undeclared identifier is reported only once for
each function it appears in
IN: libs/libc/libc.a -> staging/libc.a mb_m.c:177:32: error:
'eMBMasterASCIIStop' undeclared (first use in this function)
  177 |   pvMBMasterFrameStopCur = eMBMasterASCIIStop;
  |^~
mb_m.c:178:32: error: 'eMBMasterASCIISend' undeclared (first use in this
function); did you mean 'eMBMasterClose'?
  178 |   peMBMasterFrameSendCur = eMBMasterASCIISend;
  |^~
  |eMBMasterClose
mb_m.c:179:35: error: 'eMBMasterASCIIReceive' undeclared (first use in this
function); did you mean 'peMBMasterFrameReceiveCur'?
  179 |   peMBMasterFrameReceiveCur = eMBMasterASCIIReceive;
  |   ^
  |   peMBMasterFrameReceiveCur
mb_m.c:181:39: error: 'xMBMasterASCIIReceiveFSM' undeclared (first use in
this function)
  181 |   pxMBMasterFrameCBByteReceived = xMBMasterASCIIReceiveFSM;
  |   ^~~~
mb_m.c:182:43: error: 'xMBMasterASCIITransmitFSM' undeclared (first use in
this function); did you mean 'pxMBMasterFrameCBTransmitFSMCur'?
  182 |   pxMBMasterFrameCBTransmitterEmpty = xMBMasterASCIITransmitFSM;
  |   ^
  |
pxMBMasterFrameCBTransmitFSMCur
mb_m.c:183:38: error: 'xMBMasterASCIITimerT1SExpired' undeclared (first use
in this function)
  183 |   pxMBMasterPortCBTimerExpired = xMBMasterASCIITimerT1SExpired;
  |  ^
mb_m.c:185:17: warning: implicit declaration of function
'eMBMasterASCIIInit'; did you mean 'eMBMasterTCPInit'?
[-Wimplicit-function-declaration]
  185 |   eStatus = eMBMasterASCIIInit(ucPort, ulBaudRate, eParity);
  | ^~
  | eMBMasterTCPInit
IN: mm/libmm.a -> staging/libmm.a make[2]: ***
[/home/alan/nuttxspace/apps/Application.mk:200:
mb_m.c.home.alan.nuttxspace.apps.modbus.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [Makefile:51: /home/alan/nuttxspace/apps/modbus_all] Error 2
make: *** [tools/LibTargets.mk:232: /home/alan/nuttxspace/apps/libapps.a]
Error 2

I think those functions should be copied from the original project and
added.

I don't have a device with Modbus ASCII to test, but if you want to help
testing I can implement it.

Best Regards,

Alan

On Tue, Apr 23, 2024 at 8:19 PM David Welshon 
wrote:

> now it can't find the header file it seems
>
> make[2]: Entering directory '/home/david/nuttxspace/apps/modbus'
>
> CC: mb_m.c
>
> arm-none-eabi-gcc -c -Wstrict-prototypes -Wno-attributes
> -Wno-unknown-pragmas -Wno-psabi -Os -fno-strict-aliasing
> -fomit-frame-pointer -fno-common -Wall -Wshadow -Wundef -ffunction-sections
> -fdata-sections -mlittle-endian -march=armv7e-m -mtune=cortex-m4
> -mfloat-abi=soft -mthumb -Wa,-mthumb -Wa,-mimplicit-it=always -isystem
> /home/david/nuttxspace/nuttx/include -D__NuttX__ -DNDEBUG -pipe -I
> "/home/david/nuttxspace/apps/include" -I
> /home/david/nuttxspace/apps/modbus/functions -I
> /home/david/nuttxspace/apps/modbus/nuttx mb_m.c -o
> mb_m.c.home.david.nuttxspace.apps.modbus.o
>
> mb_m.c:54:12: fatal error: mbascii.h: No such file or directory
>
> 54 | # include "mbascii.h"
>
> | ^~~
>
> compilation terminated.
>
> make[2]: *** [/home/david/nuttxspace/apps/Application.mk:200:
> mb_m.c.home.david.nuttxspace.apps.modbus.o] Error 1
>
> make[2]: Leaving directory '/home/david/nuttxspace/apps/modbus'
>
> make[1]: *** [Makefile:51: /home/david/nuttxspace/apps/modbus_all] Error 2
>
> make: *** [tools/LibTargets.mk:232: /home/david/nuttxspace/apps/libapps.a]
> Error 2
>
> make[1]: Leaving directory '/home/david/nuttxspace/apps'
>
> "make all" terminated with exit code 2. Build might be incomplete.
>
> On Tue, Apr 23, 2024 at 6:21 PM Alan C. Assis  wrote:
>
> > Whoa, you are totally right!
> >
> > Currently it is this way:
> >
> >   ifeq ($(CONFIG_MODBUS_SLAVE),y)
> > CSRCS += mb.c
> >   endif
> >
> >   ifeq ($(CONFIG_MB_RTU_MASTER),y)
> > CSRCS += mb_m.c
> >   end

Re: nuttx user question

[Alan C. Assis]

Whoa, you are totally right!

Currently it is this way:

  ifeq ($(CONFIG_MODBUS_SLAVE),y)
CSRCS += mb.c
  endif

  ifeq ($(CONFIG_MB_RTU_MASTER),y)
CSRCS += mb_m.c
  endif

But I think it should be:

ifeq ($(CONFIG_MODBUS),y)

  ifeq ($(CONFIG_MODBUS_SLAVE),y)
CSRCS += mb.c
  endif

  ifeq ($(CONFIG_MODBUS_MASTER),y)
CSRCS += mb_m.c
  endif

Please test with this modification and let us know.

BR,

Alan

On Tue, Apr 23, 2024 at 6:24 PM David Welshon 
wrote:

> HI Alan.
>
> The problem is my hardware is using the ASCII protocol.  When I disabled
> ASCII and enabled RTU it compiled.  What I would like is ASCII protocol.
> It seems like mb_m.c is for modbus master and something like the following
> should be in the makefile in the modbus folder but I could be wrong. I will
> try to follow the trail later
>
> ifeq ($(CONFIG_MB_ASCII_MASTER),y)
>
> CSRCS += mb_m.c
>
> endif
>
>
>
>
> On Tue, Apr 23, 2024 at 4:58 PM Alan C. Assis  wrote:
>
> > Hi David,
> >
> > Actually ASCII and RTU enable equivalent/symetric functions.
> >
> > If you search for CONFIG_MB_ASCII_MASTER inside apps/modbus/ you will see
> > it just calls the ASCII related functions.
> > The config for RTU will call the binary (RTU) related functions.
> >
> > Try to disable ASCII master and enable RTU master to confirm.
> >
> > BR,
> >
> > Alan
> >
> > On Tue, Apr 23, 2024 at 4:46 PM David Welshon 
> > wrote:
> >
> > > When I changed from Modbus ASCII master selected to MOdbus RTU master
> it
> > > compiled.
> > > Is there extra configuration required for ASCII?
> > >
> > > On Tue, Apr 23, 2024 at 1:38 PM Alan C. Assis 
> wrote:
> > >
> > > > I just verified the apps/modbus/Makefile and noticed that mb.c is
> only
> > > > compiled when CONFIG_MODBUS_SLAVE is selected.
> > > >
> > > > It means you are enabling the modbus slave or the modbus example
> (that
> > > > assume to be slave).
> > > >
> > > > So, don't enable CONFIG_EXAMPLES_MODBUS, only EXAMPLES_MODBUSMASTER
> > > >
> > > > Maybe we need to rename CONFIG_EXAMPLES_MODBUS to
> > > > CONFIG_EXAMPLES_MODBUSSLAVE.
> > > >
> > > > Best Regards,
> > > >
> > > > Alan
> > > >
> > > > On Tue, Apr 23, 2024 at 2:23 PM David Welshon <
> david.wels...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Thanks for the help and great videos and articles Alan!
> > > > > I just went through the video tutorial again. Unfortunately,
> > modifying
> > > my
> > > > > own config as well as  the nucleo-f4x1re:f401-nsh configurations
> per
> > > the
> > > > > video still can't find the functions
> > > > >
> > > > > On Tue, Apr 23, 2024 at 12:45 PM Alan C. Assis 
> > > > wrote:
> > > > >
> > > > > > Hi David,
> > > > > >
> > > > > > These functions are there (see apps/modbus/mb.c for instance).
> > > > > >
> > > > > > Did you follow this video tutorial:
> > > > > > https://www.youtube.com/watch?v=FmJLrG4Ldow
> > > > > >
> > > > > > Best Regards,
> > > > > >
> > > > > > Alan
> > > > > >
> > > > > > On Tue, Apr 23, 2024 at 12:41 PM David Welshon <
> > > > david.wels...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I am trying to get modbus mastermode rs485 example working on
> > > > > > > nucleo-f4x1re following the example on the youtube channel.  I
> am
> > > > > getting
> > > > > > > undefined reference errors during linking and am not sure if I
> > need
> > > > to
> > > > > > > modify source or am missing a configuration option.  The
> device I
> > > am
> > > > > > > interacting with is set at a baudrate of 9600 with no parity
> > > instead
> > > > of
> > > > > > the
> > > > > > > baudrate in the video. But other than that I believe I followed
> > the
> > > > > video
> > > > > > > closely.
> > > > > > >
> > > > > > > I started modifying the nsh config up to this point and have
> > > > zerocross
> > > > > > and
>

Re: nuttx user question

[Alan C. Assis]

Hi David,

Actually ASCII and RTU enable equivalent/symetric functions.

If you search for CONFIG_MB_ASCII_MASTER inside apps/modbus/ you will see
it just calls the ASCII related functions.
The config for RTU will call the binary (RTU) related functions.

Try to disable ASCII master and enable RTU master to confirm.

BR,

Alan

On Tue, Apr 23, 2024 at 4:46 PM David Welshon 
wrote:

> When I changed from Modbus ASCII master selected to MOdbus RTU master it
> compiled.
> Is there extra configuration required for ASCII?
>
> On Tue, Apr 23, 2024 at 1:38 PM Alan C. Assis  wrote:
>
> > I just verified the apps/modbus/Makefile and noticed that mb.c is only
> > compiled when CONFIG_MODBUS_SLAVE is selected.
> >
> > It means you are enabling the modbus slave or the modbus example (that
> > assume to be slave).
> >
> > So, don't enable CONFIG_EXAMPLES_MODBUS, only EXAMPLES_MODBUSMASTER
> >
> > Maybe we need to rename CONFIG_EXAMPLES_MODBUS to
> > CONFIG_EXAMPLES_MODBUSSLAVE.
> >
> > Best Regards,
> >
> > Alan
> >
> > On Tue, Apr 23, 2024 at 2:23 PM David Welshon 
> > wrote:
> >
> > > Thanks for the help and great videos and articles Alan!
> > > I just went through the video tutorial again. Unfortunately, modifying
> my
> > > own config as well as  the nucleo-f4x1re:f401-nsh configurations per
> the
> > > video still can't find the functions
> > >
> > > On Tue, Apr 23, 2024 at 12:45 PM Alan C. Assis 
> > wrote:
> > >
> > > > Hi David,
> > > >
> > > > These functions are there (see apps/modbus/mb.c for instance).
> > > >
> > > > Did you follow this video tutorial:
> > > > https://www.youtube.com/watch?v=FmJLrG4Ldow
> > > >
> > > > Best Regards,
> > > >
> > > > Alan
> > > >
> > > > On Tue, Apr 23, 2024 at 12:41 PM David Welshon <
> > david.wels...@gmail.com>
> > > > wrote:
> > > >
> > > > > I am trying to get modbus mastermode rs485 example working on
> > > > > nucleo-f4x1re following the example on the youtube channel.  I am
> > > getting
> > > > > undefined reference errors during linking and am not sure if I need
> > to
> > > > > modify source or am missing a configuration option.  The device I
> am
> > > > > interacting with is set at a baudrate of 9600 with no parity
> instead
> > of
> > > > the
> > > > > baudrate in the video. But other than that I believe I followed the
> > > video
> > > > > closely.
> > > > >
> > > > > I started modifying the nsh config up to this point and have
> > zerocross
> > > > and
> > > > > gpio working, but I am stuck at the moment on this rs485 bit.
> > > Appreciate
> > > > > any help.
> > > > > Also, I have not participated in many mailing lists, so if I am in
> > the
> > > > > wrong place or I am breakin any etiquette rules I apologize in
> > advance
> > > > and
> > > > > appreciate your help finding any etiquette rules or posts to
> > straighten
> > > > me
> > > > > out.
> > > > >
> > > > > Attached is my build output and config file and below is a small
> > build
> > > > > output snippet.
> > > > >
> > > > > include -D__NuttX__ -DNDEBUG -D__KERNEL__ -I
> > > > > /home/david/nuttxspace/nuttx/arch/arm/src/chip -I
> > > > > /home/david/nuttxspace/nuttx/arch/arm/src/common -I
> > > > > /home/david/nuttxspace/nuttx/arch/arm/src/armv7-m -I
> > > > > /home/david/nuttxspace/nuttx/sched
> > > > >
> > > >
> > >
> >
> /home/david/nuttxspace/nuttx/boards/arm/stm32/nucleo-f4x1re/scripts/f401re.ld
> > > > > -o
> > > > >
> > > >
> > >
> >
> /home/david/nuttxspace/nuttx/boards/arm/stm32/nucleo-f4x1re/scripts/f401re.ld.tmp
> > > > >
> > > > > echo "LD: nuttx"
> > > > >
> > > > > LD: nuttx
> > > > >
> > > > > arm-none-eabi-ld --entry=__start -nostdlib --gc-sections --cref
> > > > > -Map=/home/david/nuttxspace/nuttx/nuttx.map
> > > > >
> > > >
> > >
> >
> -T/home/david/nuttxspace/nuttx/boards/arm/stm32/nucleo-f4x1re/scripts/f401re.ld.tmp
> > > > > -L /home/david/nutt

Re: nuttx user question

[Alan C. Assis]

I just verified the apps/modbus/Makefile and noticed that mb.c is only
compiled when CONFIG_MODBUS_SLAVE is selected.

It means you are enabling the modbus slave or the modbus example (that
assume to be slave).

So, don't enable CONFIG_EXAMPLES_MODBUS, only EXAMPLES_MODBUSMASTER

Maybe we need to rename CONFIG_EXAMPLES_MODBUS to
CONFIG_EXAMPLES_MODBUSSLAVE.

Best Regards,

Alan

On Tue, Apr 23, 2024 at 2:23 PM David Welshon 
wrote:

> Thanks for the help and great videos and articles Alan!
> I just went through the video tutorial again. Unfortunately, modifying my
> own config as well as  the nucleo-f4x1re:f401-nsh configurations per the
> video still can't find the functions
>
> On Tue, Apr 23, 2024 at 12:45 PM Alan C. Assis  wrote:
>
> > Hi David,
> >
> > These functions are there (see apps/modbus/mb.c for instance).
> >
> > Did you follow this video tutorial:
> > https://www.youtube.com/watch?v=FmJLrG4Ldow
> >
> > Best Regards,
> >
> > Alan
> >
> > On Tue, Apr 23, 2024 at 12:41 PM David Welshon 
> > wrote:
> >
> > > I am trying to get modbus mastermode rs485 example working on
> > > nucleo-f4x1re following the example on the youtube channel.  I am
> getting
> > > undefined reference errors during linking and am not sure if I need to
> > > modify source or am missing a configuration option.  The device I am
> > > interacting with is set at a baudrate of 9600 with no parity instead of
> > the
> > > baudrate in the video. But other than that I believe I followed the
> video
> > > closely.
> > >
> > > I started modifying the nsh config up to this point and have zerocross
> > and
> > > gpio working, but I am stuck at the moment on this rs485 bit.
> Appreciate
> > > any help.
> > > Also, I have not participated in many mailing lists, so if I am in the
> > > wrong place or I am breakin any etiquette rules I apologize in advance
> > and
> > > appreciate your help finding any etiquette rules or posts to straighten
> > me
> > > out.
> > >
> > > Attached is my build output and config file and below is a small build
> > > output snippet.
> > >
> > > include -D__NuttX__ -DNDEBUG -D__KERNEL__ -I
> > > /home/david/nuttxspace/nuttx/arch/arm/src/chip -I
> > > /home/david/nuttxspace/nuttx/arch/arm/src/common -I
> > > /home/david/nuttxspace/nuttx/arch/arm/src/armv7-m -I
> > > /home/david/nuttxspace/nuttx/sched
> > >
> >
> /home/david/nuttxspace/nuttx/boards/arm/stm32/nucleo-f4x1re/scripts/f401re.ld
> > > -o
> > >
> >
> /home/david/nuttxspace/nuttx/boards/arm/stm32/nucleo-f4x1re/scripts/f401re.ld.tmp
> > >
> > > echo "LD: nuttx"
> > >
> > > LD: nuttx
> > >
> > > arm-none-eabi-ld --entry=__start -nostdlib --gc-sections --cref
> > > -Map=/home/david/nuttxspace/nuttx/nuttx.map
> > >
> >
> -T/home/david/nuttxspace/nuttx/boards/arm/stm32/nucleo-f4x1re/scripts/f401re.ld.tmp
> > > -L /home/david/nuttxspace/nuttx/staging -L
> > > /home/david/nuttxspace/nuttx/arch/arm/src/board \
> > >
> > > -o /home/david/nuttxspace/nuttx/nuttx \
> > >
> > > --start-group -lsched -ldrivers -lboards -lc -lmm -larch -lxx -lapps
> -lfs
> > > -lbinfmt -lboard -lboard
> > > /usr/lib/gcc/arm-none-eabi/10.3.1/thumb/v7e-m/nofp/libgcc.a
> > >
> >
> /usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libm.a
> > > --end-group
> > >
> > > arm-none-eabi-ld:
> > >
> >
> /home/david/nuttxspace/nuttx/staging/libapps.a(modbus_main.c.home.david.nuttxspace.apps.examples.modbus_1.o):
> > > in function `modbus_pollthread':
> > >
> > > modbus_main.c:(.text.modbus_pollthread+0x56): undefined reference to
> > > `eMBInit'
> > >
> > > arm-none-eabi-ld: modbus_main.c:(.text.modbus_pollthread+0x82):
> undefined
> > > reference to `eMBSetSlaveID'
> > >
> > > arm-none-eabi-ld: modbus_main.c:(.text.modbus_pollthread+0x98):
> undefined
> > > reference to `eMBClose'
> > >
> > > arm-none-eabi-ld: modbus_main.c:(.text.modbus_pollthread+0x9e):
> undefined
> > > reference to `eMBEnable'
> > >
> > > arm-none-eabi-ld: modbus_main.c:(.text.modbus_pollthread+0xbe):
> undefined
> > > reference to `eMBPoll'
> > >
> > > arm-none-eabi-ld: modbus_main.c:(.text.modbus_pollthread+0xc4):
> undefined
> > > reference to `eMBDisable'
> > >
> > > arm-none-eabi-ld: modbus_main.c:(.text.modbus_pollthread+0xc8):
> undefined
> > > reference to `eMBClose'
> > >
> > > make[1]: *** [Makefile:211: nuttx] Error 1
> > >
> > > make[1]: Leaving directory '/home/david/nuttxspace/nuttx/arch/arm/src'
> > >
> > > make: *** [tools/Unix.mk:546: nuttx] Error 2
> > >
> > > "make all" terminated with exit code 2. Build might be incomplete.
> > >
> >
>

Re: nuttx user question

[Alan C. Assis]

Hi David,

These functions are there (see apps/modbus/mb.c for instance).

Did you follow this video tutorial:
https://www.youtube.com/watch?v=FmJLrG4Ldow

Best Regards,

Alan

On Tue, Apr 23, 2024 at 12:41 PM David Welshon 
wrote:

> I am trying to get modbus mastermode rs485 example working on
> nucleo-f4x1re following the example on the youtube channel.  I am getting
> undefined reference errors during linking and am not sure if I need to
> modify source or am missing a configuration option.  The device I am
> interacting with is set at a baudrate of 9600 with no parity instead of the
> baudrate in the video. But other than that I believe I followed the video
> closely.
>
> I started modifying the nsh config up to this point and have zerocross and
> gpio working, but I am stuck at the moment on this rs485 bit.  Appreciate
> any help.
> Also, I have not participated in many mailing lists, so if I am in the
> wrong place or I am breakin any etiquette rules I apologize in advance and
> appreciate your help finding any etiquette rules or posts to straighten me
> out.
>
> Attached is my build output and config file and below is a small build
> output snippet.
>
> include -D__NuttX__ -DNDEBUG -D__KERNEL__ -I
> /home/david/nuttxspace/nuttx/arch/arm/src/chip -I
> /home/david/nuttxspace/nuttx/arch/arm/src/common -I
> /home/david/nuttxspace/nuttx/arch/arm/src/armv7-m -I
> /home/david/nuttxspace/nuttx/sched
> /home/david/nuttxspace/nuttx/boards/arm/stm32/nucleo-f4x1re/scripts/f401re.ld
> -o
> /home/david/nuttxspace/nuttx/boards/arm/stm32/nucleo-f4x1re/scripts/f401re.ld.tmp
>
> echo "LD: nuttx"
>
> LD: nuttx
>
> arm-none-eabi-ld --entry=__start -nostdlib --gc-sections --cref
> -Map=/home/david/nuttxspace/nuttx/nuttx.map
> -T/home/david/nuttxspace/nuttx/boards/arm/stm32/nucleo-f4x1re/scripts/f401re.ld.tmp
> -L /home/david/nuttxspace/nuttx/staging -L
> /home/david/nuttxspace/nuttx/arch/arm/src/board \
>
> -o /home/david/nuttxspace/nuttx/nuttx \
>
> --start-group -lsched -ldrivers -lboards -lc -lmm -larch -lxx -lapps -lfs
> -lbinfmt -lboard -lboard
> /usr/lib/gcc/arm-none-eabi/10.3.1/thumb/v7e-m/nofp/libgcc.a
> /usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/lib/thumb/v7e-m/nofp/libm.a
> --end-group
>
> arm-none-eabi-ld:
> /home/david/nuttxspace/nuttx/staging/libapps.a(modbus_main.c.home.david.nuttxspace.apps.examples.modbus_1.o):
> in function `modbus_pollthread':
>
> modbus_main.c:(.text.modbus_pollthread+0x56): undefined reference to
> `eMBInit'
>
> arm-none-eabi-ld: modbus_main.c:(.text.modbus_pollthread+0x82): undefined
> reference to `eMBSetSlaveID'
>
> arm-none-eabi-ld: modbus_main.c:(.text.modbus_pollthread+0x98): undefined
> reference to `eMBClose'
>
> arm-none-eabi-ld: modbus_main.c:(.text.modbus_pollthread+0x9e): undefined
> reference to `eMBEnable'
>
> arm-none-eabi-ld: modbus_main.c:(.text.modbus_pollthread+0xbe): undefined
> reference to `eMBPoll'
>
> arm-none-eabi-ld: modbus_main.c:(.text.modbus_pollthread+0xc4): undefined
> reference to `eMBDisable'
>
> arm-none-eabi-ld: modbus_main.c:(.text.modbus_pollthread+0xc8): undefined
> reference to `eMBClose'
>
> make[1]: *** [Makefile:211: nuttx] Error 1
>
> make[1]: Leaving directory '/home/david/nuttxspace/nuttx/arch/arm/src'
>
> make: *** [tools/Unix.mk:546: nuttx] Error 2
>
> "make all" terminated with exit code 2. Build might be incomplete.
>

[OT] Apache NuttX Powers World's Smallest Lunar Robot

[Alan C. Assis]

Dear NuttXers,

Probably all saw about it, case don't here it goes:

https://developer.sony.com/posts/apache-nuttx-powers-worlds-smallest-lunar-robot-in-japans-historic-autonomous-lunar-exploration-mission

This is a small step for humanity, but a great step to an RTOS.

Best Regards,

Alan

Re: [Article] Rust Custom Target for QEMU RISC-V on NuttX

[Alan C. Assis]

Thank you Lup!

On Sat, Apr 20, 2024 at 10:26 PM Lee, Lup Yuen  wrote:

> Thanks Alan! The green phosphor display comes from the "cool-retro-term"
> Terminal Emulator, I used the Apple II settings :-)
>
> https://github.com/Swordfish90/cool-retro-term
>
> Lup
>
> On Sun, Apr 21, 2024 at 7:01 AM Alan C. Assis  wrote:
>
> > Hi Lup,
> >
> > Nice article! I enjoyed that green phosphor effect, how did you do it?
> >
> > Best Regards,
> >
> > Alan
> >
> > On Sat, Apr 20, 2024 at 7:41 PM Lee, Lup Yuen  wrote:
> >
> > > Last article we were compiling Rust Apps for NuttX QEMU (RISC-V
> 32-bit).
> > > And we hit a baffling error…
> > >
> > > "Can't link Soft-Float modules with Double-Float modules"
> > >
> > > Let’s solve the problem! In this article we dive inside the internals
> of
> > > C-to-Rust Interop…
> > >
> > > (1) Rust compiles for Soft-Float, NuttX expects Double-Float (Software
> vs
> > > Hardware Floating-Point)
> > >
> > > (2) But Rust doesn’t support Double-Float (by default)
> > >
> > > (3) So we create a Rust Custom Target for Double-Float
> > >
> > > (4) Rebuild the Rust Core Library for Double-Float
> > >
> > > (5) And our Rust App builds OK with NuttX!
> > >
> > > Here's how: https://lupyuen.codeberg.page/articles/rust4.html
> > >
> > > Lup
> > >
> >
>

Re: [Article] Rust Custom Target for QEMU RISC-V on NuttX

[Alan C. Assis]

Hi Lup,

Nice article! I enjoyed that green phosphor effect, how did you do it?

Best Regards,

Alan

On Sat, Apr 20, 2024 at 7:41 PM Lee, Lup Yuen  wrote:

> Last article we were compiling Rust Apps for NuttX QEMU (RISC-V 32-bit).
> And we hit a baffling error…
>
> "Can't link Soft-Float modules with Double-Float modules"
>
> Let’s solve the problem! In this article we dive inside the internals of
> C-to-Rust Interop…
>
> (1) Rust compiles for Soft-Float, NuttX expects Double-Float (Software vs
> Hardware Floating-Point)
>
> (2) But Rust doesn’t support Double-Float (by default)
>
> (3) So we create a Rust Custom Target for Double-Float
>
> (4) Rebuild the Rust Core Library for Double-Float
>
> (5) And our Rust App builds OK with NuttX!
>
> Here's how: https://lupyuen.codeberg.page/articles/rust4.html
>
> Lup
>

Re: nsh: i2c: command not found

[Alan C. Assis]

Hi Gustavo,

Could you please share a simplified version of your code that triggers this
issue?

Probably there is some memory leaking in your application or even in the
i2ctool (less probably, but we need to investigate).

Best Regards,

Alan

On Thu, Apr 18, 2024 at 12:31 PM Gustavo Soares <
gustavo.felipesoa...@hotmail.com> wrote:

> Hi everyone!
>
> I've built an application that sends i2c set/get commands to NuttX using
> the system() function in a loop that breaks after a timer runs out. After
> some i2c requests, NuttX prompts the message 'nsh: i2c: command not found'
> and the only way to solve it is rebooting the ESP32.
>
> This is what I tried so far:
> 1. Enabling i2c reset command and sending it every time i2c get/set fails,
> but it won't work because it depends on i2c driver;
> 2. Enabling the reboot command, but of course it resets the board so the
> app stops;
>
> Some more details:
> * I2c debug tool shows no error (only that one message);
> * Killing the program and sending any i2c command from console works fine;
> * Depending on the scenario, the error raises after sending around 3000
> i2c requests.
>
> Is there any other way how to reset the i2c driver without rebooting the
> board? Forcing a delay at every request significantly reduces the amount of
> i2c requests, but it does not solve the problem.
>
>
>
>

Re: Install NuttX on Rockchip RK3568

[Alan C. Assis]

Hi Артём,

I think I missed this email, apologies for that!

I just found it today because I searched on the Internet for RK3568 and
NuttX!

Do you by chance think about the idea of running NuttX on Boyhom M17?

Best Regards,

Alan

On Wed, Mar 6, 2024 at 2:13 AM Артём Денушев 
wrote:

>
> Hello, we have a goal to put Nuts on a board with Rockchip RK3568 on
> board. Can you please tell me how to download to the Nuttx board. No good
> and detailed guides were found on the Internet. Is it also possible to
> download Nuttx via USB? Because this type of download is missing in make
> menuconfig.
>
> --
> Артём Детушев
> Отправлено из Почты  Mail.ru

Re: Problem with mmcsd

[Alan C. Assis]

Hi Ahmad,

Did you add support for your custom board correctly? This that come to my
mind:

1) Did you have configured and enabled the right source clock?
2) Did you have configured the right pins at
boards/arm/stm32f7/yourboard/include/board.h ?
3) Did you create a similar file like
boards/arm/stm32f7/nucleo-144/src/stm32_sdio.c to detect and initialize
your card?
or boards/arm/stm32h7/linum-stm32h753bi/src/stm32_sdmmc.c (although it is
STM32H7, it is very similar).
4) Did you enable all necessary configs to your board? It is similar what
we have to STM32H7 board:
boards/arm/stm32h7/linum-stm32h753bi/configs/sdcard/defconfig

Best regards,

Alan

On Sun, Apr 14, 2024 at 11:13 AM Ahmad Noori  wrote:

> Hi
>
> I have a custom board with stm32h743vit6
> I port nuttx to this board and i am using it.
> I have problem with mmcsd sdio and i cant mount sd card. I get error 19
> when mount sd card.
>
> I test my hardware with stm32cubeide and its ok.
>
> Please help me to solve this problem.
> Thank you
>

Re: paid support to understand and resolve some open issues

[Alan C. Assis]

Hi Andrew,

This is a nice idea!

So, currently these two are the most critical issues, right?

Best Regards,

Alan

On Thu, Apr 11, 2024 at 8:44 PM Andrew Dennison <
andrew.denni...@motec.com.au> wrote:

> Hi Alan,
>
> We have reported the main problems we have observed in the example issues
> mentioned below (#9840 and #11189) and also have some open PR for
> performance related features. Our desire is to focus our team on product
> functionality so we would like to offer to fund someone to help with any
> Nuttx challenges we have so we can get them resolved without relying on
> community members to generously donate their time.
>
> In #9840, for example, we provided an example that demonstrates something
> we observed but also suspect that the Linux Test Project _may_ also be
> useful to confirm if this is a Nuttx problem.
>
> As you mentioned, having something in ostest to detect the issue and verify
> the fix / catch regressions would be ideal.
>
> Kind regards,
>
> Andrew Dennison
> Chief Architect and Hardware Team Lead
>
> On Thu, 11 Apr 2024 at 04:18, Alan C. Assis  wrote:
>
> > Hi Andrew,
> >
> > Could you please open a public issue to report these issues (case you
> > haven't yet).
> >
> > Also if you have some testing examples to trigger these issues, we could
> > include it into our ostest to avoid it happening again.
> >
> > BR,
> >
> > Alan
> >
> > On Tue, Apr 9, 2024 at 3:45 AM Andrew Dennison <
> > andrew.denni...@motec.com.au>
> > wrote:
> >
> > > Hi Nuttx community,
> > >
> > > We are actively working with nuttx and RISCV (RV32) and have
> contributed
> > > several PR to improve support for kernel mode with litex:
> > >
> > >
> >
> https://nuttx.apache.org/docs/latest/platforms/risc-v/litex/cores/vexriscv_smp/index.html
> > > .
> > >
> > > Along the way we have identified several issues and would like to offer
> > to
> > > pay for someone with appropriate experience to investigate and upstream
> > any
> > > fixes identified. Some examples:
> > >
> > > Experiencing possible race condition with pthread_cond_timedwait. #9840
> > > <https://github.com/apache/nuttx/issues/9840>
> > > Unexpected behaviour with poll and tickless scheduler #11189
> > > <https://github.com/apache/nuttx/issues/11189>
> > >
> > > Please contact us directly if you feel you could help with either of
> > these
> > > issues or potentially some of the other recent issues here:
> > > https://github.com/apache/nuttx/issues?q=is%3Aopen+author%3Ag2gps+
> > >
> > > Kind regards,
> > >
> > > Andrew Dennison
> >
>
> >
>
> --
> *MoTeC Pty Ltd*
>
> 121 Merrindale Drive
> Croydon South 3136
> Victoria Australia
> *T: *61 3 9761 5050
> *W: *www.motec.com.au <https://www.motec.com.au/>
>
>
> --
>  <http://www.facebook.com/motec.global>
> <http://www.youtube.com/user/MoTeCAustralia>
> <https://www.instagram.com/motec_global/>
> <https://www.linkedin.com/company/motec-global>
>
>
> --
>  <https://www.motec.com.au>
>
> --
>
>
> Disclaimer Notice: This message, including any attachments, contains
> confidential information intended for a specific individual and purpose
> and
> is protected by law. If you are not the intended recipient you should
> delete this message. Any disclosure, copying, or distribution of this
> message or the taking of any action based on it is strictly prohibited.
>

[OT] Last days to submit proposals to the VI NuttX International Workshop

[Alan C. Assis]

Dear NuttXers,

If you didn't submit your proposal, please hurry up, the last day is April
14.

More info:
https://events.nuttx.apache.org

BR,

Alan

Re: paid support to understand and resolve some open issues

[Alan C. Assis]

Hi Andrew,

Could you please open a public issue to report these issues (case you
haven't yet).

Also if you have some testing examples to trigger these issues, we could
include it into our ostest to avoid it happening again.

BR,

Alan

On Tue, Apr 9, 2024 at 3:45 AM Andrew Dennison 
wrote:

> Hi Nuttx community,
>
> We are actively working with nuttx and RISCV (RV32) and have contributed
> several PR to improve support for kernel mode with litex:
>
> https://nuttx.apache.org/docs/latest/platforms/risc-v/litex/cores/vexriscv_smp/index.html
> .
>
> Along the way we have identified several issues and would like to offer to
> pay for someone with appropriate experience to investigate and upstream any
> fixes identified. Some examples:
>
> Experiencing possible race condition with pthread_cond_timedwait. #9840
> 
> Unexpected behaviour with poll and tickless scheduler #11189
> 
>
> Please contact us directly if you feel you could help with either of these
> issues or potentially some of the other recent issues here:
> https://github.com/apache/nuttx/issues?q=is%3Aopen+author%3Ag2gps+
>
> Kind regards,
>
> Andrew Dennison
> Chief Architect and Hardware Team Lead
>
> --
> *MoTeC Pty Ltd*
>
> 121 Merrindale Drive
> Croydon South 3136
> Victoria Australia
> *T: *61 3 9761 5050
> *W: *www.motec.com.au 
>
>
> --
>  
> 
> 
> 
>
>
> --
>  
>
> --
>
>
> Disclaimer Notice: This message, including any attachments, contains
> confidential information intended for a specific individual and purpose
> and
> is protected by law. If you are not the intended recipient you should
> delete this message. Any disclosure, copying, or distribution of this
> message or the taking of any action based on it is strictly prohibited.
>

Re: Nano-x porting

[Alan C. Assis]

Hi Pavel,

Thank you very much for that!

Actually Shijo decided not to participate in GSoC2024, but opted to do the
port in his free time.

I'm also interested in Nano-X support on NuttX because we could use FLTK
with it and maybe we could get Dillo Browser running with it as well.

BR,

Alan

On Wed, Apr 10, 2024 at 2:31 AM Pavel Pisa  wrote:

> Hello Lup
>
> On Wednesday 10 of April 2024 06:57:00 Lee, Lup Yuen wrote:
> > Hi Pavel: I'm sorry the GSoC Proposal Submission has closed last week.
> > Though Shijo is still keen to do NanoX on NuttX in his spare time.
> >
> > I asked Shijo to bounce some ideas with you. If you could help him, that
> > would be great. Thanks :-)
>
> Yes, I want to help and I have interrest in the project,
> so I try to help when I am pinged. If I do not respond
> in a week, please, send me reminder. I am really busy with
> teaching at CTU and remotely in https://spacemaster.eu/ where
> CTU participates, so my remaining energy is limited.
>
> It is shame that the Nano-X for NuttX has not succeed
> in NuttX GSoC.
>
> I have thought that
>   Add X11 graphic support on NuttX using NanoX
> has been on the official list of proposed project.
>
> But project wort to try anyway. I expect that use for
> GDI and local functions calls would work smoothly.
> Nano-X layer which allows remote access and rendering
> is really interesting but I expect that its speed
> (responsiveness) will be limited on MCUs.
> On the other hand speed of today MCUs is higher
> than PCs in middle of 90 and full featured X11
> worked on them and has been with Slackware Linux my
> main and only desktop these days. So even this
> setup worth to test on NuttX if it will work
> good enough.
>
> Best wishes,
>
> Pavel
> --
> Pavel Pisa
>
> e-mail: p...@cmp.felk.cvut.cz
> Department of Control Engineering FEE CVUT
> Karlovo namesti 13, 121 35, Prague 2
> university: http://control.fel.cvut.cz/
> personal:   http://cmp.felk.cvut.cz/~pisa
> company:https://pikron.com/ PiKRON s.r.o.
> Kankovskeho 1235, 182 00 Praha 8, Czech Republic
> projects:   https://www.openhub.net/accounts/ppisa
> social: https://social.kernel.org/ppisa
> CAN related:http://canbus.pages.fel.cvut.cz/
> RISC-V education: https://comparch.edu.cvut.cz/
> Open Technologies Research Education and Exchange Services
> https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
>

Re: Paid contribution of a board configuration for w5500-evb-pico?

[Alan C. Assis]

Hi Lars,

Nice to know you found someone to work on this board.

This board is low cost fixes and integrates the W5500 Ethernet SPI chip.

Please consider integrating it into the mainline to let more people to test
and evolve the original port.

BR,

Alan

On Mon, Apr 8, 2024 at 12:26 PM Lars Kruse  wrote:

> Hello,
>
>
> Am Mon, 8 Apr 2024 16:00:35 +0200
> schrieb Lars Kruse :
>
> > If someone is interested in doing this work, then I would appreciate
> private
> > answers. I am sure, we will find a fair agreement.
>
> indeed I already received an answer and I am confident, that this will
> work out.
> Thus, please consider my query to be finished.
>
> @list: Thanks for your attention / sorry for distracting you ...
>
> Cheers,
> Lars
>

Re: [Article] Rust Apps on NuttX with QEMU RISC-V Emulator

[Alan C. Assis]

Great! I'm looking forward to it!

BR,

Alan

On Sun, Apr 7, 2024 at 12:23 PM Lee, Lup Yuen  wrote:

> Thanks Alan! Yep our GSoC Project will create Rust Wrappers for the NuttX
> POSIX API. So we won't need `extern` and `unsafe` in our Rust Apps.
>
> We'll borrow the features from the Rustix Project. Though we'll pick a
> smaller subset that's easier to maintain.
>
> Lup
>
> On Sun, Apr 7, 2024 at 8:39 PM Alan C. Assis  wrote:
>
> > Very nice article!
> >
> > I think it should be nice to take a look at the Rustix project again, it
> > will avoid these 'extern "C" ' for each function on NuttX.
> >
> > BR,
> >
> > Alan
> >
> > On Sat, Apr 6, 2024 at 7:57 PM Lee, Lup Yuen  wrote:
> >
> > > This article explains the current steps for running barebones Rust Apps
> > on
> > > NuttX and the challenges we faced:
> > >
> > > (1) How we compile Rust Apps for NuttX
> > > (2) Running NuttX and Rust Apps on QEMU RISC-V Emulator
> > > (3) Console Input and Output for Rust on NuttX
> > > (4) Software vs Hardware Floating-Point and why it’s a problem
> > > (5) Linking Issues with the Rust Panic Handler
> > > (6) Standard vs Embedded Rust and why it matters
> > > (7) Why we’re doing all this for Google Summer of Code (GSoC)
> > >
> > > Here's the article: https://lupyuen.codeberg.page/articles/rust3.html
> > >
> > > Mr Rushabh Gala is my GSoC Mentee, when the project begins I'll do the
> > > proper intro. Stay tuned :-)
> > >
> > > Lup
> > >
> >
>

Re: [Article] Rust Apps on NuttX with QEMU RISC-V Emulator

[Alan C. Assis]

Very nice article!

I think it should be nice to take a look at the Rustix project again, it
will avoid these 'extern "C" ' for each function on NuttX.

BR,

Alan

On Sat, Apr 6, 2024 at 7:57 PM Lee, Lup Yuen  wrote:

> This article explains the current steps for running barebones Rust Apps on
> NuttX and the challenges we faced:
>
> (1) How we compile Rust Apps for NuttX
> (2) Running NuttX and Rust Apps on QEMU RISC-V Emulator
> (3) Console Input and Output for Rust on NuttX
> (4) Software vs Hardware Floating-Point and why it’s a problem
> (5) Linking Issues with the Rust Panic Handler
> (6) Standard vs Embedded Rust and why it matters
> (7) Why we’re doing all this for Google Summer of Code (GSoC)
>
> Here's the article: https://lupyuen.codeberg.page/articles/rust3.html
>
> Mr Rushabh Gala is my GSoC Mentee, when the project begins I'll do the
> proper intro. Stay tuned :-)
>
> Lup
>

Re: [RESULTS] Apache NuttX 12.5.0 RC0 release

[Alan C. Assis]

Hi Alin,

Please release a Apache NuttX 12.5.0 RC1 including these fixes to blue-pill
and other boards:

https://github.com/apache/nuttx-apps/pull/2344
https://github.com/apache/nuttx/pull/12038

The PR #12038 was merged without that PR #2344 that is required.

Best Regards,

Alan

On Fri, Apr 5, 2024 at 3:09 AM Alin Jerpelea  wrote:

> Hi all,
>
> The vote to release Apache NuttX 12.5.0-rc0 is now closed.
> Thanks to those that took the time to review and vote.
>
> The release has passed with 4 +1 (binding 1 +1 (non binding) and 1 -1
> (binding) votes.
>
> Binding:
> +1 Roberto Bucher
> +1 Lup Yuen Lee
> -1 Alan C. Assis
> + Tiago Medicci Serrano
> +1 Alin Jerpelea
>
> Non Binding
> +1 yfliu2008
>
> Vote thread
> https://lists.apache.org/thread/lv8gjbpmj3nwhgmf795kvwvjxv49hzhr
>

Re: how to add unique_id for Raspberry Pi Pico?

[Alan C. Assis]

Should it be:

#if CONFIG_BOARDCTL_UNIQUEID_SIZE <= RP2040_FLASH_ID_SIZE ?

BR,

Alan

On Mon, Apr 1, 2024 at 5:45 PM Anders  wrote:

> Hi,
>
> The unique id solution for the Raspberry Pi by Adam and his team works
> very well. However, I suggest a slight modification of the code. In short,
> if the number of bytes of the NuttX unique id is configured equal to the
> actual number of bytes of the id in the Pico flash hardware system (8
> bytes), the hardware id is just copied and not used as a PRNG seed. If the
> configured size of the NuttX unique id is larger than the flash hardware,
> the PRNG code is used to return a unique id with more (non-zero) bytes. The
> advantage of having the function returning the actual hardware id, is that
> this is easily compared to the id returned by the Pico SDK function.
> Remember that the number of bytes (bits) in the flash hardware id sets a
> limit on how many unique ids there are, even if those are embedded
> (distributed) in a larger number of bytes (bits), as is the result of the
> PRNG function.
>
> The suggested code (from the
> boards/arm/rp2040/common/src/rp2040_uniqueid.c):
>
> void rp2040_uniqueid_initialize(void)
> {
>   uint8_t  txbuf[RP2040_FLASH_ID_BUFFER_SIZE];
>   uint8_t  rxbuf[RP2040_FLASH_ID_BUFFER_SIZE];
>
>   memset(g_uniqueid, 0xac, CONFIG_BOARDCTL_UNIQUEID_SIZE);
>   memset(txbuf, 0, RP2040_FLASH_ID_BUFFER_SIZE);
>   memset(rxbuf, 0, RP2040_FLASH_ID_BUFFER_SIZE);
>   txbuf[0] = RP2040_FLASH_RUID_CMD;
>
>   rp2040_flash_cmd(txbuf, rxbuf, RP2040_FLASH_ID_BUFFER_SIZE);
>
> #if CONFIG_BOARDCTL_UNIQUEID_SIZE == RP2040_FLASH_ID_SIZE
>   for (int i = 0; i < CONFIG_BOARDCTL_UNIQUEID_SIZE; i++)
> {
>   g_uniqueid[i] = rxbuf[i + RP2040_FLASH_ID_BUFFER_OFFSET];
> }
> #else
>   /* xorshift PRNG: */
>   uint64_t x;
>   x = *(uint64_t *)(rxbuf + RP2040_FLASH_ID_BUFFER_OFFSET);
>   for (int i = 0; i < CONFIG_BOARDCTL_UNIQUEID_SIZE; i++)
> {
>   x ^= x >> 12;
>   x ^= x << 25;
>   x ^= x >> 27;
>   g_uniqueid[i] = (uint8_t)((x * 0x2545f4914f6cdd1dull) >> 32);
> }
> #endif
> }
>
> Any comments?
>
> Anders
>
>
>
>
> On Monday, 18 March 2024 at 06:51, Anders 
> wrote:
>
> > Hello Adam
> >
> > Excellent! Precisely what I was looking for. I'll check it out.
> >
> > Thanks,
> > Anders
> >
> > On Sunday, 17 March 2024 at 12:54, Adam Comley a...@novators.net wrote:
> >
> > > Hi Anders,
> > >
> > > I recently had a need for this feature as well, and put together a PR
> > > based on the pico-sdk implementation. See:
> > >
> > > https://github.com/apache/nuttx/pull/11927
> > >
> > > Hope this helps.
> > >
> > > -- Adam
>

Re: [VOTE] Apache NuttX 12.5.0 RC0 release

[Alan C. Assis]

-1

1) free is not working on blue-pill)

---

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/arm-none-eabi/11.2.1/lto-wrapper
Target: arm-none-eabi
Configured with:
/data/jenkins/workspace/GNU-toolchain/arm-11/src/gcc/configure
--target=arm-none-eabi
--prefix=/data/jenkins/workspace/GNU-toolchain/arm-11/build-arm-none-eabi/install//
--with-gmp=/data/jenkins/workspace/GNU-toolchain/arm-11/build-arm-none-eabi/host-tools
--with-mpfr=/data/jenkins/workspace/GNU-toolchain/arm-11/build-arm-none-eabi/host-tools
--with-mpc=/data/jenkins/workspace/GNU-toolchain/arm-11/build-arm-none-eabi/host-tools
--with-isl=/data/jenkins/workspace/GNU-toolchain/arm-11/build-arm-none-eabi/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=release --enable-languages=c,c++,fortran --with-newlib
--with-multilib-list=aprofile,rmprofile --with-pkgversion='GNU Toolchain
for the Arm Architecture 11.2-2022.02 (arm-11.14)' --with-bugurl=
https://bugs.linaro.org/
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 11.2.1 20220111 (GNU Toolchain for the Arm Architecture
11.2-2022.02 (arm-11.14))


$ ./tools/configure.sh stm32f103-minimum:nsh

$ make -j

$ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c
"reset halt" -c "stm32f1x unlock 0" -c "reset halt" -c "flash write_image
erase nuttx.bin 0x0800"

NuttShell (NSH) NuttX-12.5.0

nsh> uname -a
NuttX 12.5.0 34f182c62a Apr  1 2024 10:37:35 arm stm32f103-minimum

nsh> free
nsh> mount
nsh> mount -t procfs /proc
nsh> free
nsh> mount
nsh>

---

2) usbnsh output is not working (I reported it two weeks ago, still not
fixed)

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/arm-none-eabi/11.2.1/lto-wrapper
Target: arm-none-eabi
Configured with:
/data/jenkins/workspace/GNU-toolchain/arm-11/src/gcc/configure
--target=arm-none-eabi
--prefix=/data/jenkins/workspace/GNU-toolchain/arm-11/build-arm-none-eabi/install//
--with-gmp=/data/jenkins/workspace/GNU-toolchain/arm-11/build-arm-none-eabi/host-tools
--with-mpfr=/data/jenkins/workspace/GNU-toolchain/arm-11/build-arm-none-eabi/host-tools
--with-mpc=/data/jenkins/workspace/GNU-toolchain/arm-11/build-arm-none-eabi/host-tools
--with-isl=/data/jenkins/workspace/GNU-toolchain/arm-11/build-arm-none-eabi/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=release --enable-languages=c,c++,fortran --with-newlib
--with-multilib-list=aprofile,rmprofile --with-pkgversion='GNU Toolchain
for the Arm Architecture 11.2-2022.02 (arm-11.14)' --with-bugurl=
https://bugs.linaro.org/
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 11.2.1 20220111 (GNU Toolchain for the Arm Architecture
11.2-2022.02 (arm-11.14))


$ ./tools/configure.sh stm32f103-minimum:usbnsh

$ make -j

$ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c
"reset halt" -c "stm32f1x unlock 0" -c "reset halt" -c "flash write_image
erase nuttx.bin 0x0800"


NuttShell (NSH) NuttX-12.5.0

nsh> uname -a
nsh> help
nsh> ?
nsh>

BR,

Alan


On Mon, Apr 1, 2024 at 4:43 AM Alin Jerpelea  wrote:

> Hello all,
> Apache NuttX 12.5.0 RC0 has been staged under [1] and it's
> time to vote on accepting it for release. Voting will be open for 72hr.
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1 are
> required to pass.
>
> The Apache requirements for approving a release can be found here [3]
> "Before voting +1 PMC members are required to download the signed
> source code package, compile it as provided, and test the resulting
> executable on their own platform, along with also verifying that the
> package meets the requirements of the ASF policy on releases."
>
> A document to walk through some of this process has been published on
> our project wiki and can be found here [4].
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [4])
> [ ] -1 reject (explanation required)
>
> Thank you all,
> Alin Jerpelea
>
> SCM Information:
>   Release tag: nuttx-12.5.0-RC0
>   Hash for the release nuttx tag: 34f182c62a857ce1911138e202028616c70a2ac6
>   Hash for the release nuttx-apps tag:
> e2805fc9c451afa0953502152c2a61f4a40d6ba5
>
> [1] https://dist.apache.org/repos/dist/dev/nuttx/12.5.0-RC0/
> [2]
> https://raw.githubusercontent.com/apache/nuttx/nuttx-12.5.0-RC0/ReleaseNotes
> [3] https://www.apache.org/dev/release.html#approving-a-release
> [4]
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
>

Re: [VOTE] Apache NuttX 12.5.0 RC0 release

[Alan C. Assis]

Roberto,

Please send information about your toolchain (i.e. use: arm-none-eabi-gcc
-v) and the final binary size (i.e.: arm-none-eabi-size nuttx).

BR,

Alan

On Mon, Apr 1, 2024 at 5:46 AM Roberto Bucher 
wrote:

> +1
>
> Built for:
>
> nucleo-144:f746-pysim
> nucleo-h745zi:pysim_cm7
> nucleo-h743zi2:pysim
>
> Generated export for nucleo-144:f746-pysim and tested with pysimCoder
>
> Ciao
>
> Roberto
>
> On 4/1/24 9:41 AM, Alin Jerpelea wrote:
> > Hello all,
> > Apache NuttX 12.5.0 RC0 has been staged under [1] and it's
> > time to vote on accepting it for release. Voting will be open for 72hr.
> >
> > A minimum of 3 binding +1 votes and more binding +1 than binding -1 are
> > required to pass.
> >
> > The Apache requirements for approving a release can be found here [3]
> > "Before voting +1 PMC members are required to download the signed
> > source code package, compile it as provided, and test the resulting
> > executable on their own platform, along with also verifying that the
> > package meets the requirements of the ASF policy on releases."
> >
> > A document to walk through some of this process has been published on
> > our project wiki and can be found here [4].
> >
> > [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> > items in [4])
> > [ ] -1 reject (explanation required)
> >
> > Thank you all,
> > Alin Jerpelea
> >
> > SCM Information:
> >Release tag: nuttx-12.5.0-RC0
> >Hash for the release nuttx tag:
> 34f182c62a857ce1911138e202028616c70a2ac6
> >Hash for the release nuttx-apps tag:
> e2805fc9c451afa0953502152c2a61f4a40d6ba5
> >
> > [1] https://dist.apache.org/repos/dist/dev/nuttx/12.5.0-RC0/
> > [2]
> https://raw.githubusercontent.com/apache/nuttx/nuttx-12.5.0-RC0/ReleaseNotes
> > [3] https://www.apache.org/dev/release.html#approving-a-release
> > [4]
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
> >
>
>

Re: [OT] GSoC: We still have two projects waiting for contributors

[Alan C. Assis]

Hi Jan,

I'm sorry to hear that because you appear to be the right person for this
project and your experience developing robots will be essential to validate
everything is working as expected.

But I completely understand your point (I faced similar challenges on my
Master Degree as well), the ideal should be conciating GSoC with something
related to your master degree.

If you think it could be possible, please ping me.

Best Regards,

Alan

On Sun, Mar 24, 2024 at 6:00 PM Jan Kaniuka  wrote:

> Hi everyone,
> thank you for Friday's meeting, where I was able to learn more about the
> GSoC 2024 program. The project to improve the integration of micro-ROS with
> NuttX sounds interesting, but after further consideration, I cannot
> undertake it. This project requires 350 hours of work - I am not able
> to combine it with my regular job and my master's thesis. I hope that you
> will be able to find a person who will undertake this project. Over the
> last few days, I have learned a little about NuttX and in my free time I
> would love to test it on one of my microcontrollers :-)
>
> Best Regards,
> Jan
>
> czw., 21 mar 2024 o 19:07 Jan Kaniuka  napisał(a):
>
> > Hi Alan,
> >
> > I received your invitation and confirmed my attendance at the meeting.
> See
> > you tomorrow :)
> >
> > Regards,
> > Jan
> >
> > czw., 21 mar 2024 o 15:51 Alan C. Assis  napisał(a):
> >
> >> Hi Jan,
> >>
> >> Thank you for that nice introduction!
> >>
> >> You are right, NuttX will bring the flexibility you have using Raspberry
> >> Pi
> >> W with Linux, without the drawbacks (boot time, power consumption, board
> >> price, etc).
> >>
> >> The idea of this project is to get Micro-ROS better integrated on NuttX,
> >> maybe even bringing some required tools (like *Fast DDS/*uXRCE-DDS)
> >> directly to nuttx-apps.
> >>
> >> Tomorrow the NuttX mentors and Mentees will have the first meeting, I'll
> >> send you the invitation.
> >>
> >> Best Regards,
> >>
> >> Alan
> >>
> >> On Thu, Mar 21, 2024 at 11:18 AM Jan Kaniuka 
> wrote:
> >>
> >> > Hi everyone,
> >> >
> >> > I'm Jan, I'm 24 years old, and I’m a second-year master's
> undergraduate
> >> > student in automatic control and robotics at Warsaw University of
> >> > Technology. I have 3 years of experience with robot programming using
> >> ROS
> >> > 2. Furthermore, I am also the president of "BIONIK - Students Robotics
> >> > Interest Club at Warsaw University of Technology". Apart from
> >> programming,
> >> > interaction with real hardware is important to me. I have experience
> in
> >> > programming STM32 L4/ L0/F4 microcontrollers. In addition to my
> >> studies, I
> >> > work as a software engineer in R projects in the field of robotics.
> As
> >> > part of my master's thesis, I am working on controlling a team of
> >> > heterogeneous robots (manipulators and mobile robots) using ROS 2 and
> I
> >> > decided to use micro-ROS in it. Recently, I managed to run micro-ROS
> on
> >> > ESP32 with FreeRTOS and I also plan to run it on RPi Pico W.
> >> >
> >> > So far, I have only heard of NuttX in the context of micro-ROS (First
> >> > micro-ROS Application on an RTOS
> >> > <https://micro.ros.org/docs/tutorials/core/first_application_rtos/>).
> >> > NuttX
> >> > looks interesting, because we do not always need, for example, an RPi
> >> with
> >> > an OS and 8 GB of RAM - sometimes just a simple 8-bit MCU is enough.
> I'd
> >> > love to know more details about "Micro-ROS integration on NuttX". Does
> >> this
> >> > task consist of "refreshing" the code and preparing some kind of demo
> >> > application?
> >> >
> >> > Regards,
> >> > Jan
> >> >
> >> >
> >> > czw., 21 mar 2024 o 13:32 Alan C. Assis 
> napisał(a):
> >> >
> >> > > Very nice Tomek!
> >> > >
> >> > > Welcome aboard Jan! We are glad to know you are interested to
> >> participate
> >> > > of GSoC as a NuttX contributor.
> >> > >
> >> > > Best Regards,
> >> > >
> >> > > Alan
> >> > >
> >> > > On Thu, Mar 21, 2024 at 12:50 AM Tomek CEDRO 
> >> wrote:
> >> > >
> &

Please test your board: Some recent modification

[Alan C. Assis]

Very everyone,

It seems like some recent modification in the mainline generated some bad
side effects, none command is working. I'm pretty sure everything was
working yesterday!

If you have a Bluepill board you can try to reproduce it this way:

$ git clone https://github.com/apache/nuttx-apps apps

$ git clone https://github.com/apache/nuttx

$ cd nuttx

$ ./tools/configure.sh stm32f103-minimum:usbnsh

$ make -j

$ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c init -c
"reset halt" -c "stm32f1x unlock 0" -c "reset halt" -c "flash write_image
erase nuttx.bin 0x0800"

Reset the board and connect to /dev/ttyACM0 @ 115200 8n1

NuttShell (NSH) NuttX-12.4.0
nsh> help
nsh> uname -a
nsh> ls /dev
nsh>

No error, no output, nothing, only the prompt still alive!

This is another call for a CI Hardware Testing!!!

Best Regards,

Alan

Re: YOLO machine learning on nuttx and more

[Alan C. Assis]

Hi Justin,

Welcome to NuttX!!!

There are many people contributing things to NuttX and to be honest I
didn't know NuttX had support for YOLO until I saw your email.

I'm glad you are here because we need Documentation to it:
https://nuttx.apache.org/docs/latest/applications/mlearing/darknet/index.html

So, if you investigate further this topic, please consider submitting a
documentation or even a beginner tutorial :-)

About your other question, you can use initrc script to start-up your
application:
https://www.youtube.com/watch?v=jYvCe8yQ1OY

Best Regards,

Alan



On Fri, Mar 22, 2024 at 8:34 AM justin linotte 
wrote:

> Hello, i do not master Nuttx deeply, but i want to create a system using
> Computer vision to naviguate
> I develop my system on a raspberry pi pico board with nuttx on it and i
> see in the docs that there is support for machine learning like YOLO
> (you only look once), but there is no more documentation on it.
> Because i'm stuck at this level, i ask for help here, i hope it's the
> good place and that someone can help me ;)
>
> I also have another secondary question, but i think that if i search
> more i can find by myself, but if you want to answer, its nice from you.
> when i make with the usbnsh config, the apps obvioulsy not start at
> system startup, and the way i can run the is through my serial monitor
> CLI, so how to have a process start at boot, and maybe restart if it exit?
>

Re: [OT] GSoC: We still have two projects waiting for contributors

[Alan C. Assis]

Hi Jan,

Thank you for that nice introduction!

You are right, NuttX will bring the flexibility you have using Raspberry Pi
W with Linux, without the drawbacks (boot time, power consumption, board
price, etc).

The idea of this project is to get Micro-ROS better integrated on NuttX,
maybe even bringing some required tools (like *Fast DDS/*uXRCE-DDS)
directly to nuttx-apps.

Tomorrow the NuttX mentors and Mentees will have the first meeting, I'll
send you the invitation.

Best Regards,

Alan

On Thu, Mar 21, 2024 at 11:18 AM Jan Kaniuka  wrote:

> Hi everyone,
>
> I'm Jan, I'm 24 years old, and I’m a second-year master's undergraduate
> student in automatic control and robotics at Warsaw University of
> Technology. I have 3 years of experience with robot programming using ROS
> 2. Furthermore, I am also the president of "BIONIK - Students Robotics
> Interest Club at Warsaw University of Technology". Apart from programming,
> interaction with real hardware is important to me. I have experience in
> programming STM32 L4/ L0/F4 microcontrollers. In addition to my studies, I
> work as a software engineer in R projects in the field of robotics. As
> part of my master's thesis, I am working on controlling a team of
> heterogeneous robots (manipulators and mobile robots) using ROS 2 and I
> decided to use micro-ROS in it. Recently, I managed to run micro-ROS on
> ESP32 with FreeRTOS and I also plan to run it on RPi Pico W.
>
> So far, I have only heard of NuttX in the context of micro-ROS (First
> micro-ROS Application on an RTOS
> <https://micro.ros.org/docs/tutorials/core/first_application_rtos/>).
> NuttX
> looks interesting, because we do not always need, for example, an RPi with
> an OS and 8 GB of RAM - sometimes just a simple 8-bit MCU is enough. I'd
> love to know more details about "Micro-ROS integration on NuttX". Does this
> task consist of "refreshing" the code and preparing some kind of demo
> application?
>
> Regards,
> Jan
>
>
> czw., 21 mar 2024 o 13:32 Alan C. Assis  napisał(a):
>
> > Very nice Tomek!
> >
> > Welcome aboard Jan! We are glad to know you are interested to participate
> > of GSoC as a NuttX contributor.
> >
> > Best Regards,
> >
> > Alan
> >
> > On Thu, Mar 21, 2024 at 12:50 AM Tomek CEDRO  wrote:
> >
> > > On Wed, Mar 20, 2024 at 1:04 AM Alan C. Assis 
> wrote:
> > > > Hi NuttX users and developers,
> > > > We have two projects that are still missing contributors: Device Tree
> > and
> > > > MicroROS.
> > >
> > > I have asked my friend Tomasz WINIARSKI that is Robotics Professor at
> > > Warsaw University of Technology (Poland) and mentor of Student
> > > Scientific Group "BIONIK" as I saw they play with Robotics + MicroROS.
> > >
> > > Tomasz recommended Jan KANIUKA that has already practical experience
> > > with embedded systems, robotics, MicroROS and works with it as part of
> > > his MSc thesis :-)
> > >
> > > I would like to recommend Jan KANIUKA as the developer for the NuttX +
> > > MicroROS GSoC 2024 project :-)
> > >
> > > Jan already joined the dev@ mailing list so we can discuss the
> > > details.. Jan are you here? :-)
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
> >
>

Re: [OT] GSoC: We still have two projects waiting for contributors

[Alan C. Assis]

Very nice Tomek!

Welcome aboard Jan! We are glad to know you are interested to participate
of GSoC as a NuttX contributor.

Best Regards,

Alan

On Thu, Mar 21, 2024 at 12:50 AM Tomek CEDRO  wrote:

> On Wed, Mar 20, 2024 at 1:04 AM Alan C. Assis  wrote:
> > Hi NuttX users and developers,
> > We have two projects that are still missing contributors: Device Tree and
> > MicroROS.
>
> I have asked my friend Tomasz WINIARSKI that is Robotics Professor at
> Warsaw University of Technology (Poland) and mentor of Student
> Scientific Group "BIONIK" as I saw they play with Robotics + MicroROS.
>
> Tomasz recommended Jan KANIUKA that has already practical experience
> with embedded systems, robotics, MicroROS and works with it as part of
> his MSc thesis :-)
>
> I would like to recommend Jan KANIUKA as the developer for the NuttX +
> MicroROS GSoC 2024 project :-)
>
> Jan already joined the dev@ mailing list so we can discuss the
> details.. Jan are you here? :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: [OT] GSoC: We still have two projects waiting for contributors

[Alan C. Assis]

Hi Roberto,

Thank you for this update!

I think MicroROS needs more care from the NuttX community, it opens the
door for low cost robots solutions, that otherwise will require powerful
boards running ROS and Linux.

We don't have a contributor interested to work on this project for GSoC
yet, so we don't need a mentor for it yet.

Best Regards,

Alan

On Wed, Mar 20, 2024 at 5:00 AM Roberto Bucher <
roberto.bucher.2...@gmail.com> wrote:

> Hi Alan
>
> at present, my previous MicroROS git doesn't compile correctly (I think
> that something has changed in the original git). I can help to find out
> the problem if required, but, as you now, I'm retired now and I can't
> follow students in the GSoC!
>
> Ciao
>
> Roberto
>
> On 3/20/24 1:02 AM, Alan C. Assis wrote:
> > Hi NuttX users and developers,
> >
> > We have two projects that are still missing contributors: Device Tree and
> > MicroROS.
> >
> > This is the listing of projects and contributors interested on each
> project:
> >
> > Rust integration on NuttX
> > -
> > Contributor: RUSHABH GALA
> >
> >
> > NuttX NAND Flash Subsystem
> > --
> > Contributor: Saurav Pal
> >
> >
> > TinyGL support on NuttX
> > ---
> > Contributor: Victor Suarez Rovere
> >
> >
> > Add X11 graphic support on NuttX using NanoX
> > 
> > Contributor: Shijo George
> >
> >
> > Device Tree support for NuttX
> > -
> > Contributor: ?
> >
> >
> > Micro-ROS integration on NuttX
> > --
> > Contributor: ?
> >
> > If you want to participate, please let me know.
> >
> > Each contributor needs to prepare the Proposal before April 2!
> >
> > It is important to remember that not all projects will be accepted by
> GSoC,
> > because ASF has a limited slot (I don't know how many slots Google
> reserves
> > for Apache).
> >
> > Best Regards,
> >
> > Alan
> >
>
>

[OT] GSoC: We still have two projects waiting for contributors

[Alan C. Assis]

Hi NuttX users and developers,

We have two projects that are still missing contributors: Device Tree and
MicroROS.

This is the listing of projects and contributors interested on each project:

Rust integration on NuttX
-
Contributor: RUSHABH GALA


NuttX NAND Flash Subsystem
--
Contributor: Saurav Pal


TinyGL support on NuttX
---
Contributor: Victor Suarez Rovere


Add X11 graphic support on NuttX using NanoX

Contributor: Shijo George


Device Tree support for NuttX
-
Contributor: ?


Micro-ROS integration on NuttX
--
Contributor: ?

If you want to participate, please let me know.

Each contributor needs to prepare the Proposal before April 2!

It is important to remember that not all projects will be accepted by GSoC,
because ASF has a limited slot (I don't know how many slots Google reserves
for Apache).

Best Regards,

Alan

Re: Run app when device starts

[Alan C. Assis]

Oops, where I wrote "former", should be "later"

On Monday, March 18, 2024, Alan C. Assis  wrote:

> Hi Gustavo,
>
> You can do it over init script (there is a video at NuttX Channel) or
> using NuttX Init Entry Point, replacing nsh_main with your app_main name.
>
> In the former case, you need to initialize all device driver before your
> application attempts to use it. So, early board initialize and late board
> initialize features can help here.
>
> Best Regards,
>
> Alan
>
> On Monday, March 18, 2024, Gustavo Soares  com> wrote:
>
>> Hello!
>>
>> I've built an application to run on NuttX and I'd like to know if it's
>> possible to make it start when the device starts so I don't have to connect
>> into the console to run it.
>>
>>

Re: Run app when device starts

[Alan C. Assis]

Hi Gustavo,

You can do it over init script (there is a video at NuttX Channel) or using
NuttX Init Entry Point, replacing nsh_main with your app_main name.

In the former case, you need to initialize all device driver before your
application attempts to use it. So, early board initialize and late board
initialize features can help here.

Best Regards,

Alan

On Monday, March 18, 2024, Gustavo Soares 
wrote:

> Hello!
>
> I've built an application to run on NuttX and I'd like to know if it's
> possible to make it start when the device starts so I don't have to connect
> into the console to run it.
>
>

Re: Query regarding compatibilty

[Alan C. Assis]

Hi Azam,

No, the inicial port to RaspberryPi was discontinued and moved to obsolet
Repo into Bitbucket.

>From time to time people come here asking for it and some event said they
planned to reactivated that port. But until now nothing happened.

The only Raspberry board supported by NuttX is the Raspberry Pi Pico, the
uses an RP2040 MCU instead of a high-end processor.

Best Regards,

Alan

On Sunday, March 17, 2024, Azam Naqvi  wrote:

> Hello all,
> Hope you are doing well.
>
> I have a question regarding RTOS if it is compatible with raspberry pi 3B
> as I checked somewhere so but got confused as somewhere it was that it is
> supported or not?
>
>
> have a nice day
>
> Regards,
> Azam
>

Re: Rust in the OS?

[Alan C. Assis]

I think there is a reference project that we can use as base:

https://github.com/tylerwhall/zephyr-rust

It doesn't seem to implement the drivers or anything else in the kernel.

Best Regards,

Alan


On Wed, Mar 13, 2024 at 8:36 PM Tomek CEDRO  wrote:

> On Wed, Mar 13, 2024 at 10:03 PM Gregory Nutt wrote:
> > On 3/13/2024 2:42 PM, Tomek CEDRO wrote:
> > > You want Rust in the core go ahead write RustOS have fun maintaining
> it for 5 years and show us its better :-)
> >
> > You are probably right in that.  It would probably be necessary have to
> > be a different OS if any extensive amount of Rust is used.  POSIX
> > defines a C interface to the OS with C function prototypes and C data
> > types.  I haven't looked at this carefully, but a significant use of
> > Rust might jeopardize POSIX compatibility (or require a mess of C
> > conversion wrappers).  It would probably be better to have a pure RustOS
> > with a non-POSIX, but POSIX-like OS interface.
> >
> > I am not a language chauvinist, but I think we should avoid the
> > complexity and maintenance issues of a mixed language solution (as
> > enumerated by others in this thread).
>
> I can see Lup is already on the GH thread this is good news :-) I
> would suggest to limit Rust for the Application part and see how it
> works.. just as we have Basic, Python, Lua, Zig, etc working on top of
> existing untouched POSIX RTOS architecture.. then create several demos
> using display sound etc to show others how to port Rust applications
> to NuttX :-)
>
>
> Below are my concerns in depth for our internal discussion.. maybe you
> have similar thoughts.. and you can safely ignore that part :-)
>
> There are some Rust based OS already out there. Look how many! Some of
> them does not even plan to support security mitigations, sensor
> devices, BLE, WIFI, etc. Why? How does setup of those Rust OS SDK
> compares to current NuttX environment setup and build times??
>
> https://github.com/flosse/rust-os-comparison
>
> Instead of injecting unimaginable maintenance nightmare into existing
> minimalistic projects Rust fans can simply focus on building new
> alternative solutions and prove these are better in practice - by
> results - they need to build commercial products on top of their OS,
> ship it, maintain it, take full responsibility for the results, after
> some years we will see how it works. I will be first to congratulate
> and buy a good Open-Source based Rust product. But right now that push
> for injecting Rust into all possible OS/RTOS seems really suspicious
> not to say viral and dangerous!!
>
> Lup can do magic with NuttX like running applications written in other
> programming languages and convert NuttX code to different programming
> languages in order to run on new platforms and environments. All is
> done in non-invasive way, respecting current architecture and backward
> compatibility, adding new functionality that is optional and diamond
> clean in maintenance. This is the only way to go! :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: how to add unique_id for Raspberry Pi Pico?

[Alan C. Assis]

Hi Anders,

As I said the RP2040 doesn't have a unique id like others MCUs, then the
solution they found was read from its SPI Flash, more info:

https://github.com/raspberrypi/pico-sdk/pull/12

You need to look how they did it and use it in NuttX.

BR,

Alan

On Thu, Mar 14, 2024 at 4:09 AM Anders  wrote:

> Hello Alan and thanks for the warm welcome.
>
> Yes, the id is in the flash part of the board and the code for extracting
> the unique id is in the Pico bootrom. But how to acces and run bootrom code
> from a Nuttx application?
> The code for other boards seem to access an id in a processor register.
> And while access to flash fs on the Pico supposedly could give some hints,
> a solution still eludes me.
>
> Anders
>
>  Originalmeddelande --------
> Den 25 feb. 2024 20:17, Alan C. Assis skrev:
>
> > Hi Anders, Welcome to NuttX !!! Yes, you are right, the rp2040 port
> doesn't yet have support for uniqueid. If you want to add it, please enter
> inside nuttx/arch/arm/src/ and "git grep uniqueid" for a reference how it
> is done in other chips. Example in cxd56xx arch:
> arch/arm/src/cxd56xx/cxd56_uid.c And cxd56xx common boards:
> boards/arm/cxd56xx/common/src/cxd56_uid.c Notice that rp2040 doesn't have
> unique id like other chips, but you have use the flash serial number as
> unique id, more info:
> https://forums.raspberrypi.com/viewtopic.php?t=331910 BR, Alan On Sun,
> Feb 25, 2024 at 9:58 AM Anders  wrote: > Having just started to play with
> nuttx running on Raspberry Pi Pico, I > discovered that configuring support
> for the unique id functions results in > a build of nuttx that fails. My
> understanding is that support for this is > not currently added. One can
> find code for this for other boards in the > corresponding directory tree
> of nuttx. > > Reading in the archives of this list, it is not recommended
> to use > functions from the Pico-sdk. So new driver code should be added. >
> > What is the recommended way of adding this functionality? Adding the >
> interface in a separate file of boards/arm/rp2040/raspberry-pi-pico/src/ >
> and Make.defs seems easy. But where would the code for actually interfacing
> > with the flash best go? > > Anders

Re: Rust in the OS?

[Alan C. Assis]

I think we will never have "full community support" because it means
something like "unanimity" and as a guy called Nelson Rodrigues once said:
"All unanimity is dumb".

Although (fortunately) we don't have full community support, it seems we
have a direction: only application support for now.

Best Regards,

Alan

On Wed, Mar 13, 2024 at 7:17 PM Gregory Nutt  wrote:

>
> On 3/13/2024 4:11 PM, Alan C. Assis wrote:
> > I think we are having a CMakefile deja-vu here, don't we? (I hope we
> don't
> > lose any developer this time)
>
> Let's make sure that we have full concurrence from the community.  Our
> responsibility is to serve the whole community and not just the special
> interests of a few.  That is what it means to be an Apache project.
>
> The CMake effort did not have full community support.  Let's make sure
> that we do this time.
>
>

Re: Rust in the OS?

[Alan C. Assis]

I think we are having a CMakefile deja-vu here, don't we? (I hope we don't
lose any developer this time)

The goal of improving Rust on NuttX is to get better support for our
current "integration" (that is not implemented the right way, actually it
is just a wrapper currently, we had a presentation from the Rustix author
explaining the issues).

So, the idea is just to get things prepared, in case in the future someone
really needs to integrate some external driver implemented on Rust (who
knows?).

That is the initial propose (from 3 years ago) :
https://issues.apache.org/jira/browse/NUTTX-5

If someone wants to improve it, please do it!

Best Regards,

Alan

On Wed, Mar 13, 2024 at 6:03 PM Gregory Nutt  wrote:

>
> On 3/13/2024 2:42 PM, Tomek CEDRO wrote:
> > You want Rust in the core go ahead write RustOS have fun maintaining it
> for 5 years and show us its better :-)
>
> You are probably right in that.  It would probably be necessary have to
> be a different OS if any extensive amount of Rust is used.  POSIX
> defines a C interface to the OS with C function prototypes and C data
> types.  I haven't looked at this carefully, but a significant use of
> Rust might jeopardize POSIX compatibility (or require a mess of C
> conversion wrappers).  It would probably be better to have a pure RustOS
> with a non-POSIX, but POSIX-like OS interface.
>
> I am not a language chauvinist, but I think we should avoid the
> complexity and maintenance issues of a mixed language solution (as
> enumerated by others in this thread).
>

Re: Re: Re:Re: mm/mm_heap assertion error

[Alan C. Assis]

Please watch video #54 at NuttX Channel, I explained how to use it.

I think we are missing a documentation about it here:
Documentation/applications/system/stackmonitor/index.rst

Best Regards,

Alan

On Tue, Mar 12, 2024 at 9:15 AM yfliu2008  wrote:

> Alan, thank you!
>
>
> did you mean this SCHED_STACK_RECORD thing? I set 32 for that and can see
> things like below on the target:
>
>
>  remote cat /proc/3/stack 
> StackAlloc: 0x7092000
>  StackBase: 0x7092050
>  StackSize: 4016
>  StackMax:  118042624
>  SizeBacktrace
>  StackUsed: 1552
>
>
>
>
> The "StackMax" above is 0x7093000 (118042624). But how can this work
> for the short-lived threads like "AppBringUp" thread?
>
>
>
> Regards,
> yf
>
>
>
>
> Original
>
>
>
> From:"Alan C. Assis"< acas...@gmail.com ;
>
> Date:2024/3/12 18:56
>
> To:"dev"< dev@nuttx.apache.org ;
>
> Subject:Re: Re:Re: mm/mm_heap assertion error
>
>
> You can use the stack monitor to see the stack consumption.
>
> Best Regards,
>
> Alan
>
> On Tue, Mar 12, 2024 at 7:38 AM yfliu2008  wrote:
>
>  Dear experts,
> 
> 
> 
>  After enlarging the stack size of "AppBringUp" thread, the
> remote
>  node can boot NSH on RPMSGFS now. I am sorry for not trying this
> earlier. I
>  was browsing the "rpmsgfs.c" blindly and noticed a few auto variables
>  defined in the stack... then I thought it might worth a try so I did
> it.
> 
> 
>  Now I am still unclear about why small stack leads to heap corruption?
>  Also how we can read this stack issue from stackdump logs? Let
> me
>  know if you have any hints.
> 
> 
>  Regards,
>  yf
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  Original
> 
> 
> 
>  From:"yfliu2008"< yfliu2...@qq.com ;
> 
>  Date:2024/3/12 15:10
> 
>  To:"dev"< dev@nuttx.apache.org ;
> 
>  Subject:Re:Re: mm/mm_heap assertion error
> 
> 
>  Nathan,
> 
> 
>  Here I disabled RPMsg UART device initialization but the crash still
>  happens, I don't see other options to disable for now. On the other
> hand,
>  if we choose not mounting NSH from the RPMSGFS, it can boot smoothly
> and
>  after boot we can manually mount the RPMSGFS for playing.
> 
> 
> 
> 
>  I uploaded the logs, callstacks and ELFs at
>  https://github.com/yf13/hello/tree/debug-logs/nsh-rpmsgfs . There
> are two
>  sets from two ELFs created from same code base but with different
> DEBUG _xx
>  configs. The crash happens earlier in the build with more debug
>  options.
> 
> 
>  Please let me know if you have any more suggestions.
> 
> 
>  Regards,
>  yf
> 
> 
> 
> 
>  Original
> 
> 
> 
>  From:"Nathan Hartman"< hartman.nat...@gmail.com ;
> 
>  Date:2024/3/12 1:27
> 
>  To:"dev"< dev@nuttx.apache.org ;
> 
>  Subject:Re: mm/mm_heap assertion error
> 
> 
>  What's needed is some way to binary search where the culprit is.
> 
>  If I understand correctly, it looks like the crash is happening in the
>  later stages of board bring-up? What is running before that? Can parts
>  be disabled or skipped to see if the problem goes away?
> 
>  Another idea is to try running a static analysis tool on the sources
>  and see if it finds anything suspicious to be looked into more
>  carefully.
> 
> 
>  On Mon, Mar 11, 2024 at 10:00 AM Gregory Nutt  wrote:
>  
>   The reason that the error is confusing is because the error
> probably
>  did
>   not occur at the time of the assertion; it probably occurred much
>  earlier.
>  
>   In most crashes due to heap corruption there are two players:
> the
>   culprit and the victim threads.  The culprit thread actually
> cause the
>   corruption.  But at the time of the corruption, no error
> occurs.  The
>   error will not occur until later.
>  
>   So sometime later, the victim thread runs, encounters the
> clobbered
>  heap
>   and crashes.  In this case, "AppBringup" and "rptun" are
> potential
>   victim threads.  The fact that they crash tell you very little
> about
>  the
>   culprit.
>  
>   On 3/10/2024 6:51 PM, yfliu2008 wrote:
>Gregory, thank you for the analysis.
>   
>   
>   
>   
>The crashes happened during system booting up, mostly at
>  "AppBringup" or "rptun" threads, as per the assertion logs. The other
>  threads existing are the "idle" and the "lpwork" threads as per the
> sched
>  logs. There should 

Re: Re:Re: mm/mm_heap assertion error

[Alan C. Assis]

You can use the stack monitor to see the stack consumption.

Best Regards,

Alan

On Tue, Mar 12, 2024 at 7:38 AM yfliu2008  wrote:

> Dear experts,
>
>
>
> After enlarging the stack size of "AppBringUp" thread, the remote
> node can boot NSH on RPMSGFS now. I am sorry for not trying this earlier. I
> was browsing the "rpmsgfs.c" blindly and noticed a few auto variables
> defined in the stack... then I thought it might worth a try so I did it.
>
>
> Now I am still unclear about why small stack leads to heap corruption?
> Also how we can read this stack issue from stackdump logs? Let me
> know if you have any hints.
>
>
> Regards,
> yf
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Original
>
>
>
> From:"yfliu2008"< yfliu2...@qq.com ;
>
> Date:2024/3/12 15:10
>
> To:"dev"< dev@nuttx.apache.org ;
>
> Subject:Re:Re: mm/mm_heap assertion error
>
>
> Nathan,
>
>
> Here I disabled RPMsg UART device initialization but the crash still
> happens, I don't see other options to disable for now. On the other hand,
> if we choose not mounting NSH from the RPMSGFS, it can boot smoothly and
> after boot we can manually mount the RPMSGFS for playing.
>
>
>
>
> I uploaded the logs, callstacks and ELFs at
> https://github.com/yf13/hello/tree/debug-logs/nsh-rpmsgfs . There are two
> sets from two ELFs created from same code base but with different DEBUG _xx
> configs. The crash happens earlier in the build with more debug
> options.
>
>
> Please let me know if you have any more suggestions.
>
>
> Regards,
> yf
>
>
>
>
> Original
>
>
>
> From:"Nathan Hartman"< hartman.nat...@gmail.com ;
>
> Date:2024/3/12 1:27
>
> To:"dev"< dev@nuttx.apache.org ;
>
> Subject:Re: mm/mm_heap assertion error
>
>
> What's needed is some way to binary search where the culprit is.
>
> If I understand correctly, it looks like the crash is happening in the
> later stages of board bring-up? What is running before that? Can parts
> be disabled or skipped to see if the problem goes away?
>
> Another idea is to try running a static analysis tool on the sources
> and see if it finds anything suspicious to be looked into more
> carefully.
>
>
> On Mon, Mar 11, 2024 at 10:00 AM Gregory Nutt  wrote:
> 
>  The reason that the error is confusing is because the error probably
> did
>  not occur at the time of the assertion; it probably occurred much
> earlier.
> 
>  In most crashes due to heap corruption there are two players:  the
>  culprit and the victim threads.  The culprit thread actually cause the
>  corruption.  But at the time of the corruption, no error occurs.  The
>  error will not occur until later.
> 
>  So sometime later, the victim thread runs, encounters the clobbered
> heap
>  and crashes.  In this case, "AppBringup" and "rptun" are potential
>  victim threads.  The fact that they crash tell you very little about
> the
>  culprit.
> 
>  On 3/10/2024 6:51 PM, yfliu2008 wrote:
>   Gregory, thank you for the analysis.
>  
>  
>  
>  
>   The crashes happened during system booting up, mostly at
> "AppBringup" or "rptun" threads, as per the assertion logs. The other
> threads existing are the "idle" and the "lpwork" threads as per the sched
> logs. There should be no other threads as NSH creation is still
> ongoing. As for interruptions, the UART and IPI are running in kernel
> space and MTIMER are in NuttSBI space. The NSH is loaded from a
> RPMSGFS volume, thus there are a lot RPMSG communications.
>  
>  
>  
>  
>   Is the KASAN proper for use in Kernel mode?
>  
>  
>   With MM_KASAN_ALL it reports a read access error:
>  
>  
>  
>   BCkasan_report: kasan detected a read access error, address at
> 0x708fe90,size is 8, return address: 0x701aeac
>  
>   _assert: Assertion failed panic: at file: kasan/kasan.c:117
> task: Idle_Task process: Kernel 0x70023c0
>  
>  
>   The call stack looks like:
>  
>  
>   #0 _assert (filename=0x7060f78 "kasan/kasan.c",
> linenum=117, msg=0x7060ff0 "panic", regs=0x7082720   #2
> 0x070141d6 in kasan_report (addr=0x708fe90, size=8,
> is_write=false, return_address=0x701aeac   #3
> 0x07014412 in kasan_check_report (addr=0x708fe90, size=8,
> is_write=false, return_address=0x701aeac   #4
> 0x0701468c in __asan_load8_noabort (addr=0x708fe90) at
> kasan/kasan.c:315
>   #5 0x0701aeac in riscv_swint (irq=0,
> context=0x708fe40, arg=0x0) at common/riscv_swint.c:133
>   #6 0x0701b8fe in riscv_perform_syscall
> (regs=0x708fe40) at common/supervisor/riscv_perform_syscall.c:45
>   #7 0x07000570 in sys_call6 ()
>  
>  
>  
>   With MM_KASAN_DISABLE_READ_CHECKS=y, it reports:
>  
>  
>   _assert: Assertion failed : at file: mm_heap/mm_malloc.c:245
> task: rptun process: Kernel 0x704a030
>  
>  
>   The call stack is:
>  
>  
>   #0 _assert (filename=0x7056060 "mm_heap/mm_malloc.c",
> linenum=245, msg=0x0, regs=0x7082720   #2 0x07013082
> in mm_malloc (heap=0x7089c00, size=128) at mm_heap/mm_malloc.c:245
>   #3 0x07011694 in kmm_malloc (size=128) at
> kmm_heap/kmm_malloc.c:51

Re: BMI160 on Nordic nRF52832-dk Kit

[Alan C. Assis]

Hi Mauro,

I think there is some issue in your SPI (I don't know if it is in your
configuration, or on your wiring, or in our device, or something else).

The issue you are seeing (only 1 bit transmitted) could be confirmed by
this error message:

nrf52_spi_exchange: Incomplete transfer wrote 536915151 expected 1

Looking at your configuration I noticed you enabled the char driver
support, but it is not required for native SPI drivers, it is used only for
testing.

(*) SPI character driver

It will create a /dev/spi0 that could be used to test SPI communication
directly, but since you are not using SPI test application, I think it is
not necessary.

I also noticed that 536915151 is 0x2000ACCF, which seems like a memory
pointer, which raises my suspicion there is some misconfiguration issue.

There are only two boards that currently have support for this sensor and
they used I2C.

So, I suggest you test first using I2C, since you can use a board as
reference. Or maybe someone working with this chip could help (not sure if
Raiden00 has this chip).

BR,

Alan

On Sun, Mar 3, 2024 at 6:08 PM Mauro Sollar  wrote:

> Hi,
>
> I made the recommended change and it compiled normally, but I saw that the
> code was missing the implementation of the CS signal, so I made the changes
> below and it still didn't work. Does the code really work for the
> nRF52832-DK? I used my logic analyzer and there is no information on the
> data line, only 1 in the 8 bits, but there is the rise and fall of the
> signal, I also checked the clock and it is ok! This is very confusing for
> me, I thought it would be easier to use the example of this BMI160 sensor.
> If you have any further help I would appreciate it again! Thanks!
>
> == vi
> ./boards/arm/nrf52/nrf52832-dk/src/nrf52_bringup.c
>
> #include "nrf52_spi.h"
> #include 
>
> int nrf52_bringup(void)
> {
>   int ret;
> ...
> ...
> ...
>
>   struct spi_dev_s *dev = nrf52_spibus_initialize(0);
>   <<<--- Added by me
>   ret = bmi160_register("/dev/accel0", dev);
>  <<<---
>   if (ret < 0)
>  <<<---
> {
>  <<<---
>   syslog(LOG_ERR, "ERROR: bmi160_register failed: %d\n", ret);
> <<<---
> }
>  <<<---
>
> ...
> ...
> ...
>
>
> }
>
>
> == vi
> ./boards/arm/nrf52/nrf52832-dk/include/board.h
>
> #define BOARD_SPI0_CS_PIN  (GPIO_OUTPUT | GPIO_VALUE_ONE | GPIO_PORT0 |
> GPIO_PIN(11))<<<--- Added by me
> #define BOARD_SPI0_INT_PIN (GPIO_OUTPUT | GPIO_PORT0 | GPIO_PIN(12))
><<<---
>
> vi ./arch/arm/src/board/board/nrf52832-dk.h e adicione as linhas abaixo:
>
> /* BMI160 pins
>  * CS   - P0.11
>  * INT  - P0.12
>  */
>
> #define GPIO_BMI160_CS(GPIO_OUTPUT | GPIO_VALUE_ONE | GPIO_PORT0 |
> GPIO_PIN(11))   <<<--- Added by me
> #define GPIO_BMI160_INT   (GPIO_INPUT  | GPIO_PORT0 | GPIO_PIN(12))
>  <<<---
>
>
> == vi
> ./boards/arm/nrf52/nrf52832-dk/src/nrf52_spi.c
>
>
> void nrf52_spidev_initialize(void)
> {
> #ifdef CONFIG_NRF52_SPI0_MASTER
> #  ifdef CONFIG_IEEE802154_MRF24J40
>   /* Configure the SPI-based MRF24J40 chip select GPIO */
>
>   spiinfo("Configure GPIO for MRF24J40 SPI1/CS\n");
>
>   nrf52_gpio_config(GPIO_MRF24J40_CS);
>   nrf52_gpio_write(GPIO_MRF24J40_CS, true);
> #  endif
> #  ifdef CONFIG_SENSORS_BMI160
> <<<--- Added by me
>   /* Configure the SPI-based BMI160 chip select GPIO */  <<<---
>
>   spiinfo("Configure GPIO for BMI160 SPI0/CS\n");<<<---
>
>   nrf52_gpio_config(GPIO_BMI160_CS); <<<---
>   nrf52_gpio_write(GPIO_BMI160_CS, true);<<<---
> #  endif
><<<---
> #endif
> }
>
> ifdef CONFIG_NRF52_SPI0_MASTER
> void nrf52_spi0select(struct spi_dev_s *dev, uint32_t devid,
>   bool selected)
> {
>   spiinfo("devid: %08lx CS: %s\n",
>   (unsigned long)devid, selected ? "assert" : "de-assert");
>
>   spiinfo("BMI160 device %s\n",<<<---
> Added by me
>   selected ? "asserted" : "de-asserted");  <<<---
>   /* Set the GPIO low to select and high to de-select */   <<<---
>   nrf52_gpio_write(GPIO_BMI160_CS, !selected); <<<---
>
>   switch (devid)
> {
> #ifdef CONFIG_IEEE802154_MRF24J40
> case SPIDEV_IEEE802154(0):
> {
>   spiinfo("MRF24J40 device %s\n",
>   selected ? "asserted" : "de-asserted");
>
>   /* Set the GPIO low to select and high to de-select */
>
>   nrf52_gpio_write(GPIO_MRF24J40_CS, !selected);
>   break;
> }
> #endif
>
>   default:
> {
>   break;
> }
> }
> }
>
> uint8_t 

Re: Ethernet direct RMII connection

[Alan C. Assis]

Hi Roland,

I think the page I sent earlier has more info about MII, RMII, RGMII, etc
that you need to know before attempting to do it. Let me put here for
clarification:

"There are variants of the MII (GMII; RMII; SGMII; RGMII...) interface for
connecting MACs to PHYs or MACs to MACs, in some of them there is a MAC or
PHY role.

The RGMII interface is a dual data rate (DDR) interface that consists of a
transmit path and a receive path. Both paths have an independent clock, 4
data signals and a control signal. This means that in RGMII there is no PHY
or MAC role, so no special support is needed for MAC-to-MAC connection as
it is the case, being both ends in RGMII mode is enough for the
communication to be carried out."

Today I found a new page with more information and some details that
probably will help you and others trying to do it, like clock shifting,
otherwise it will not work:

https://community.nxp.com/t5/i-MX-Processors/Direct-ETH-MAC-MII-to-MAC-MII-connection/m-p/1042795

So, if you didn't include the clock skew circuit as shown on this link,
then you will need to use RMII.

Best Regards,

Alan

On Fri, Mar 1, 2024 at 8:31 AM Roland  wrote:

> @Alan,
>
> Thanks for the hints.
>
> From your message I will assume that this direct mode is not supported by
> default, so I need to start looking into it.
>
> I already have a basic hardware setup includes a STM32F7 custom board and
> an imx8m custom board, all prototypes. So it would be easier for me to
> start from these platforms @Nathan.
>
> As the GPIO resources are always against us, RMII would be a more
> realistic choice to me.
>
> In general level I have known it is possible, as I can find some
> successful cases in other platforms. And I will not worry too much about
> imx8m side which running Linux, which supports direct mode through RMII as
> claimed.
> I will be appreciated that if any Nuttx specific information/discussion
> about this feature that you can also share? This may prevent me from
> wasting time on something you may already explored.
>
> On hardware level, not sure if you can help to confirm my following
> understanding,
>
> 1. MDIO pins are not mandatory, so these 2 pins are not used  on current
> prototypes in order to save GPIOs for other purposes.
> 2. 50MHz Reference clock is provided from a shared crystal to feed into
> both side.
>
> All the best,
> /Roland
>
>
> > On Mar 1, 2024, at 3:14 AM, Alan C. Assis  wrote:
> >
> > Hi Roland,
> >
> > We had a discussion about it a few months ago!
> >
> > We know it is possible, but nobody until now tried to do it.
> >
> > Basically you will need RMII support on both chips, I don't remember the
> > details why MII will not work (or will be more difficult to work)
> >
> > There is a discussion about it here, maybe you can get more insights:
> >
> https://stackoverflow.com/questions/39503466/can-two-ethernet-mac-chips-be-connected-directly-without-going-thru-phy
> >
> > Best Regards,
> >
> > Alan
> >
> >
> > On Thu, Feb 29, 2024 at 2:11 PM Roland  wrote:
> >
> >> Hi,
> >>
> >> I would like to directly connect a STM32F7 processor running Nuttx, to
> an
> >> external MCU (i.e., NXP imx8m) through RMII directly, without the need
> for
> >> PHY IC in between.
> >> Is this supported by Nuttx? I checked into the documents but this direct
> >> mode seems not been mentioned anywhere.
> >> Can anyone please confirm if this is supported, or I have to change
> >> something by myself?
> >>
> >> Thank you.
> >>
> >> /Roland
> >>
> >>
>
>

Re: Ethernet direct RMII connection

[Alan C. Assis]

Hi Roland,

We had a discussion about it a few months ago!

We know it is possible, but nobody until now tried to do it.

Basically you will need RMII support on both chips, I don't remember the
details why MII will not work (or will be more difficult to work)

There is a discussion about it here, maybe you can get more insights:
https://stackoverflow.com/questions/39503466/can-two-ethernet-mac-chips-be-connected-directly-without-going-thru-phy

Best Regards,

Alan


On Thu, Feb 29, 2024 at 2:11 PM Roland  wrote:

> Hi,
>
> I would like to directly connect a STM32F7 processor running Nuttx, to an
> external MCU (i.e., NXP imx8m) through RMII directly, without the need for
> PHY IC in between.
> Is this supported by Nuttx? I checked into the documents but this direct
> mode seems not been mentioned anywhere.
> Can anyone please confirm if this is supported, or I have to change
> something by myself?
>
> Thank you.
>
> /Roland
>
>

Re: how to add unique_id for Raspberry Pi Pico?

[Alan C. Assis]

Hi Anders,

Welcome to NuttX !!!

Yes, you are right, the rp2040 port doesn't yet have support for uniqueid.

If you want to add it, please enter inside nuttx/arch/arm/src/ and "git
grep uniqueid" for a reference how it is done in other chips.

Example in cxd56xx arch:
arch/arm/src/cxd56xx/cxd56_uid.c

And cxd56xx common boards:
boards/arm/cxd56xx/common/src/cxd56_uid.c

Notice that rp2040 doesn't have unique id like other chips, but you have
use the flash serial number as unique id, more info:
https://forums.raspberrypi.com/viewtopic.php?t=331910

BR,

Alan

On Sun, Feb 25, 2024 at 9:58 AM Anders  wrote:

> Having just started to play with nuttx running on Raspberry Pi Pico, I
> discovered that configuring support for the unique id functions results in
> a build of nuttx that fails. My understanding is that support for this is
> not currently added. One can find code for this for other boards in the
> corresponding directory tree of nuttx.
>
> Reading in the archives of this list, it is not recommended to use
> functions from the Pico-sdk. So new driver code should be added.
>
> What is the recommended way of adding this functionality? Adding the
> interface in a separate file of boards/arm/rp2040/raspberry-pi-pico/src/
> and Make.defs seems easy. But where would the code for actually interfacing
> with the flash best go?
>
> Anders

Re: littlefs BIOC_FLUSH in NAND flash

[Alan C. Assis]

Hi Saurav,

Amazing! I'm happy to know you fixed it!

If you can create some board configuration or document how you are doing
it, I think it will be useful for more people here!

Some years ago Ken Petit created a small Flash Simulator to use with
SmartFS, but I think this one you are using is different.

Best Regards,

Alan

On Sat, Feb 24, 2024 at 4:22 PM Saurav Pal  wrote:

> Hi Alan,
>
> I have figured out the cause...it was because of a very *small* error in my
> rawwrite method which was confusing littlefs (which I think commits CRC,
> flushes it and rechecks the written data for consistency at one point in
> the forceformat operation).
>
> Right now, mount() works as intended. However there is a floating point
> exception that occurs if I try to cd or ls the mounted directory, and I'll
> be looking into it tomorrow (most probably a division by 0 error).
>
> Here are the logs and stats just after a mount:
> https://pastebin.com/QxJ4qMRd (it's a bit longhas stats about each of
> 4096 pages in a 2MB virtual device).
>
> PS: I had to use vi to view the logs in nsh in a sane manner, though a tool
> like less would be godsend in such cases.
>
> BR,
> SP
>
> On Sat, Feb 24, 2024 at 9:23 PM Saurav Pal  wrote:
>
> > Hi Xiang and Alan,
> >
> > Thanks for the info Xiang.
> >
> > Alan, the first error returns ENOTTY as littlefs sends a BIOC_FLUSH
> > command in IOCTL which isn't supported in NAND, and Xiang has provided
> the
> > explanation on why that is fine.
> >
> > As for the -ENOSPC, I'm looking into it currently. It *should *have
> > enough space, considering I have the virtual device with a size of 2MB +
> > (some bytes for the respective spare areas in blocks) and that is way
> more
> > than theoretical requirement of littlefs, so I'll need to debug it
> further.
> >
> > PS: I was also having a problem with the "vi" utility in the sim, any
> > movement keys (or anything I typed in general) that I typed were echoed
> out
> > the the terminal as well, so I fixed that using termios to disable echo
> > (and enable back on quitting vi).
> >
> > BR,
> > SP
> >
> > On Sat, 24 Feb, 2024, 20:18 Alan C. Assis,  wrote:
> >
> >> Hi Saurav,
> >>
> >> I suggest you to verifyr these errors first:
> >>
> >> *Command: 1293 | BIOC_FLUSH: 1293*
> >> Error Upper! ioctl | -25
> >>
> >> #define ENOTTY 25 /* Not a typewriter */
> >>
> >> So, you can search where this ENOTTY is returned.
> >>
> >> Some to:
> >>
> >> nx_mount: ERROR: Bind method failed: -28
> >> nsh: mount: mount failed: 28
> >>
> >> #define ENOSPC 28 /* No space left on device */
> >>
> >> BR,
> >>
> >> Alan
> >>
> >> On Sat, Feb 24, 2024 at 9:28 AM Saurav Pal 
> wrote:
> >>
> >> > Hi all,
> >> >
> >> > I've been trying to develop a device simulator for the NAND flash (in
> >> the
> >> > sim).
> >> >
> >> > A short note on what this does is create a virtual NAND flash (from
> RAM)
> >> > and provide a driver, as well as a wrapper around the upper half
> (which
> >> for
> >> > now, does nothing extra). This helps in creating records of
> >> > reads/writes/erases (in a separate file) for testing and statistics
> >> > purposes.
> >> >
> >> > Since littlefs is one of the supported filesystems on MTD devices, I
> >> tried
> >> > to use it to test mount but it tries to use an ioctl with BIOC_FLUSH
> in
> >> the
> >> > format process, which is not supported as far as code in
> >> > drivers/mtd/mtd_nand.c go.
> >> >
> >> > *Should that be something that the NAND driver should support?*
> >> >
> >> > Here are the logs of that process, the first ioctl is for
> >> MTDIOC_GEOMETRY
> >> > (which is supported), and second for BIOC_FLUSH (in *bold*):
> >> >
> >> > nuttx ➤ make && ./nuttx
> >> > LD:  nuttx
> >> > login: admin
> >> > password:
> >> > User Logged-in!
> >> > nsh> ls /dev
> >> > /dev:
> >> >  console
> >> >  gpio0
> >> >  gpio1
> >> >  gpio2
> >> >  gpio3
> >> >  loop
> >> >  null
> >> >  oneshot
> >> >  ram0
> >> >  ram1
> >> >  ram2
> >> >  zero
> >> > nsh> mtddev

Re: [Article] Drag-n-Drop a NuttX App

[Alan C. Assis]

WOW!!! Really cool project!

Easy way to let people who know how to program using blocky to create NuttX
applications!

Best Regards,

Alan

On Sat, Feb 24, 2024 at 7:03 PM Lee, Lup Yuen  wrote:

> Remember MakeCode? BBC micro:bit and its Drag-n-Drop App Builder? MakeCode
> for BBC micro:bit is an awesome creation that’s way ahead of its time (7
> years ago!)
> - TypeScript Compiler and Arm Assembler in the Web Browser (in JavaScript!)
> - Custom Embedded OS (CODAL + Mbed OS)
> - micro:bit Simulator in JavaScript
>
> Today 7 years later: How would we redo all this? Maybe with...
> (1) Hardware Device: Ox64 BL808 64-bit RISC-V SBC
> (2) Embedded OS: Apache NuttX RTOS
> (3) JavaScript Engine: QuickJS for NuttX
> (4) Web Emulator: TinyEMU WebAssembly for NuttX
> (5) C Compiler + Assembler: TCC WebAssembly for NuttX
> (6) Device Control: Web Serial API with Term.js
>
> This article explains how we gave MakeCode a wholesome wholesale makeover
> with NuttX:
> https://lupyuen.codeberg.page/articles/quickjs2.html
>
> Lup
>

Re: littlefs BIOC_FLUSH in NAND flash

[Alan C. Assis]

Hi Saurav,

I suggest you to verifyr these errors first:

*Command: 1293 | BIOC_FLUSH: 1293*
Error Upper! ioctl | -25

#define ENOTTY 25 /* Not a typewriter */

So, you can search where this ENOTTY is returned.

Some to:

nx_mount: ERROR: Bind method failed: -28
nsh: mount: mount failed: 28

#define ENOSPC 28 /* No space left on device */

BR,

Alan

On Sat, Feb 24, 2024 at 9:28 AM Saurav Pal  wrote:

> Hi all,
>
> I've been trying to develop a device simulator for the NAND flash (in the
> sim).
>
> A short note on what this does is create a virtual NAND flash (from RAM)
> and provide a driver, as well as a wrapper around the upper half (which for
> now, does nothing extra). This helps in creating records of
> reads/writes/erases (in a separate file) for testing and statistics
> purposes.
>
> Since littlefs is one of the supported filesystems on MTD devices, I tried
> to use it to test mount but it tries to use an ioctl with BIOC_FLUSH in the
> format process, which is not supported as far as code in
> drivers/mtd/mtd_nand.c go.
>
> *Should that be something that the NAND driver should support?*
>
> Here are the logs of that process, the first ioctl is for MTDIOC_GEOMETRY
> (which is supported), and second for BIOC_FLUSH (in *bold*):
>
> nuttx ➤ make && ./nuttx
> LD:  nuttx
> login: admin
> password:
> User Logged-in!
> nsh> ls /dev
> /dev:
>  console
>  gpio0
>  gpio1
>  gpio2
>  gpio3
>  loop
>  null
>  oneshot
>  ram0
>  ram1
>  ram2
>  zero
> nsh> mtddev
> Size:   2097152 B
>
> Pages:4096
> Blocks: 33
> Writing...Done
> Driver running
> nsh> ls /dev
> /dev:
>  console
>  gpio0
>  gpio1
>  gpio2
>  gpio3
>  loop
>  mtd
>  null
>  oneshot
>  ram0
>  ram1
>  ram2
>  zero
> nsh> mount -t littlefs -o forceformat /dev/mtd /hi
> Upper! ioctl
> Command: 1537 | BIOC_FLUSH: 1293
> Upper! bread
> Page 128
> Lower! rawread : Page 128
> Lower! rawread : Page 129
> Lower! rawread : Page 130
> Lower! rawread : Page 131
> Upper! erase
> Lower! eraseblock : Block 0
> Upper! bread
> Page 0
> Lower! rawread : Page 0
> Lower! rawread : Page 1
> Lower! rawread : Page 2
> Lower! rawread : Page 3
> Upper! bread
> Page 4
> Lower! rawread : Page 4
> Lower! rawread : Page 5
> Lower! rawread : Page 6
> Lower! rawread : Page 7
> Upper! bwrite
> Lower! rawwrite : Page 0
> Lower! rawwrite : Page 1
> Lower! rawwrite : Page 2
> Lower! rawwrite : Page 3
> Upper! ioctl
> *Command: 1293 | BIOC_FLUSH: 1293*
> Error Upper! ioctl | -25
> Upper! bread
> Page 0
> Lower! rawread : Page 0
> Lower! rawread : Page 1
> Lower! rawread : Page 2
> Lower! rawread : Page 3
> nx_mount: ERROR: Bind method failed: -28
> nsh: mount: mount failed: 28
> nsh>
>
> The logs with "Upper!" refer to the upper half of the driver being
> executed, and same for the lower, and the pages are numbered from the start
> of the device (ie. (block << LOG_N_BLOCKS_PER_PAGE) + page_in_block)).
>
> Regards,
> SP
>

Re: Re:Re: RiscV landscape

[Alan C. Assis]

Hi YF,

Right! I will do that!

Best Regards,

Alan

On Sat, Feb 24, 2024 at 9:19 AM yfliu2008  wrote:

> Alan,
>
>
>
>
>
>
> It seems this is the issue template:
> https://github.com/riscv-admin/riscv-landscape/issues/new/choose
>
>
> As I am having difficulties to access sites like linkedin, crunchbase etc
> here, not sure if I am the right person for it. Please feel free to create
> a ticket there if you have all required information.
>
>
>
> Regards,
> yf
>
>
>
>
>
>
> Original
>
>
>
> From:"yfliu2008"< yfliu2...@qq.com ;
>
> Date:2024/2/24 20:08
>
> To:"dev"< dev@nuttx.apache.org ;
>
> Subject:Re:Re: RiscV landscape
>
>
>
>
>
>
>
> From the readme page, it seems that we can also create new issue
> with required information. This one might be an reference:
> https://github.com/riscv-admin/riscv-landscape/issues/156
>
>
>
> Regards,
> yf
>
>
>
> Original
>
>
>
> From:"Alan C. Assis"< acas...@gmail.com ;
>
> Date:2024/2/24 17:49
>
> To:"dev@nuttx.apache.org"< dev@nuttx.apache.org ;
>
> Subject:Re: RiscV landscape
>
>
> Yes! It should be!
>
> What you think about the Idea of submitting a PR there?
>
> If you need the Logo in SVG I can send you!
>
> BTW, I will create a Logo page at our documentation page, this way people
> can use it easily.
>
> BR,
>
> Alan
>
> On Saturday, February 24, 2024, yfliu2008  wrote:
>
>  Hi,
> 
> 
> 
> 
>  I am wondering if NuttX can be added to the https://github.com/riscv-
>  <https://github.com/riscv->; admin/riscv-landscape list?
> 
> 
> 
> 
> 
>  Regards,
> 
>  yf

Re: RiscV landscape

[Alan C. Assis]

Yes! It should be!

What you think about the Idea of submitting a PR there?

If you need the Logo in SVG I can send you!

BTW, I will create a Logo page at our documentation page, this way people
can use it easily.

BR,

Alan

On Saturday, February 24, 2024, yfliu2008  wrote:

> Hi,
>
>
>
>
> I am wondering if NuttX can be added to the https://github.com/riscv-
> admin/riscv-landscape list?
>
>
>
>
>
> Regards,
>
> yf

Re: Deleting files with wildcard

[Alan C. Assis]

No, the issue he reported is correct: "rm *" and "rm -r *" are not
supported.

It is a missing feature.

Best Regards,

Alan

On Fri, Feb 23, 2024 at 9:04 PM Tomek CEDRO  wrote:

> Maybe the SD card filesystem is mounted read-only?
> For instance when filesystem is corrupted it may mount ready-only on
> some systems until fsck marks it clean?
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: Deleting files with wildcard

[Alan C. Assis]

Also I noticed rm doesn't accept to remove a mount point:

$ ./nuttx
login: admin
password:
User Logged-in!

nsh> umount /tmp
nsh> mount -t vfat /dev/ram2 /tmp/disk

nsh> mount
  /bin type binfs
  /etc type romfs
  /proc type procfs
  /tmp/disk type vfat

nsh> cd /tmp/disk
nsh> ls
/tmp/disk:

nsh> echo "T1" > test1
nsh> echo "T2" > test2
nsh> echo "T3" > test3

nsh> ls
/tmp/disk:
 test1
 test2
 test3

nsh> cd ..
nsh> ls
/tmp:
 disk/

nsh> rm -r disk
nsh: rm: unlink failed: 1

nsh> ls /tmp/disk
/tmp/disk:
nsh>

My idea was to mount inside a subdir and remove only it, but it also didn't
work.

Makes sense since mount points should be "removed" with umount.

About removing "." I think Linux is even more restrictive:

$ mkdir /tmp/test
$ cd /tmp/test
$ echo "T1" > test1
$ echo "T2" > test2
$ echo "T3" > test3

$ rm -r .
rm: refusing to remove '.' or '..' directory: skipping '.'

$ ls
test1  test2  test3

$ rm -r *
$ ls
$

Linux thinks I want to remove the ".", not the files "here"! So it doesn't
even remove any file.

NuttX seems to be a little bit more smart! hehehe!

Best Regards,

Alan


On Fri, Feb 23, 2024 at 9:33 PM Gregory Nutt  wrote:

>
> On 2/23/2024 6:19 PM, Gregory Nutt wrote:
> >
> >
> > On 2/23/2024 5:57 PM, Alan C. Assis wrote:
> >> /tmp:
> >>   test1
> >>   test2
> >>   test3
> >> nsh> rm -r .
> >> nsh: rm: unlink failed: 1
> >> nsh> ls
> >> /tmp:
> >> nsh>
> >>
> >> It reported error "unlink failed: 1", but removed all the files.
> >
> > 1 = EPERM, Operation not permitted
> >
> > I suspect that occurred when it tried to rm ".".   Try putting a
> > subdirectory under /tmp.  Does vfat even support the "." hardlink?
> >
> "." corresponds to the root directory of the mounted file system.
> Trying to delete  "." will result in an EPERM error on VFAT.  See
> fat/fs_fat32dirent.c, function fat_remove().
>
> It seems like there is some issue with unlink.
>
>

Re: Deleting files with wildcard

[Alan C. Assis]

I did a quick test in the sim:nsh

nsh> mount
  /bin type binfs
  /etc type romfs
  /proc type procfs
  /tmp type vfat

nsh> cd /tmp
nsh> ls
/tmp:

nsh> echo "T1" > test1
nsh> echo "T2" > test2
nsh> echo "T3" > test3
nsh> ls
/tmp:
 test1
 test2
 test3
nsh> rm -r .
nsh: rm: unlink failed: 1
nsh> ls
/tmp:
nsh>

It reported error "unlink failed: 1", but removed all the files.

BR,

Alan

On Fri, Feb 23, 2024 at 8:47 PM Alan C. Assis  wrote:

> Hi Jernej,
>
> Did you try enter inside the directory (i.e. /mnt) and run:
>
> nsh> rm -f .
>
> Maybe it helps.
>
> BR,
>
> Alan
>
> On Thu, Feb 22, 2024 at 3:55 AM Jernej Turnsek 
> wrote:
>
>> Hi, I have accidentally written a lot of files on my sdcard and now I
>> would
>> like to delete them. I have tried with rm * command and it doesn't work.
>> Is
>> there a way to delete multiple files without formatting the card?
>> Regards,
>> Jernej
>>
>

Re: Deleting files with wildcard

[Alan C. Assis]

Hi Jernej,

Did you try enter inside the directory (i.e. /mnt) and run:

nsh> rm -f .

Maybe it helps.

BR,

Alan

On Thu, Feb 22, 2024 at 3:55 AM Jernej Turnsek 
wrote:

> Hi, I have accidentally written a lot of files on my sdcard and now I would
> like to delete them. I have tried with rm * command and it doesn't work. Is
> there a way to delete multiple files without formatting the card?
> Regards,
> Jernej
>

Re: Nuttx not starting after jumping from bootloader

[Alan C. Assis]

Just a update here for people facing similar issue in the future.

Actually Jose discovered the issue was not on NuttX itself, but it was
an Interrupt enabled in the bootloader that was missing an entry IRQ
vector table.

Best Regards,

Alan

On 2/20/24, Ambrocio, Jose  wrote:
> Hello Nuttx team,
> I'm currently working on an embedded project that uses a bootloader and an
> application. The target is a STM32G0B1VCI6 chip. I'm using the initial
> address (0x0800 ) for the bootloader with 40K of size. Application
> starts at 0x0800 A000 with 216K of size. Before jumping to the application
> I'm setting the main stack pointer and configuring the vector table to point
> to the start address of the app.  I see that the app is executed but it
> remains in the function irq_initialize  and doing some debug I noticed that
> it is stuck in the assert function, in an infinite loop:
> [cid:image003.jpg@01DA63E7.A577AD90]
>
> I wonder if nuttx has some dependencies with the initial addresses or if
> there is something that must be configured before jumping. This is the code
> I have for the jumping:
>
> [cid:image004.png@01DA63E7.A577AD90]
> Where NUTTX_APPLICATION_ENTRY_POINT is 0x0800A000.
> I did a different test using another application (without nuttx) and the
> bootloader can jump without any problem and the application can be
> executed.
> I would appreciate your help. Thanks
> José Daniel Ambrocio
> Embedded SW Engineer
>

Re: Device Discovery

[Alan C. Assis]

Technically saying I didn't use the right name, it should be kernel thread.

But in fact of udev it should be a userspace daemon.

BR,

Alan

On 2/21/24, Saurav Pal  wrote:
> Hi Xiang,
>
> I meant multiple daemons in reference to what Alan mentioned about there
> being daemons to detect the various components currently. Hope this clears
> it.
>
> Regards,
> SP
>
> On Wed, Feb 21, 2024 at 12:00 PM Xiang Xiao 
> wrote:
>
>> Even though PCs just have one udev daemon, I don't see why MCU needs
>> multiple daemon.
>>
>> On Wed, Feb 21, 2024 at 2:07 PM Saurav Pal  wrote:
>>
>> > Hi,
>> >
>> > Thanks for the clarification.
>> >
>> > Also, am I right in thinking it would increase performance if there was
>> > a
>> > single daemon working rather than multiple? (I am thinking in terms of
>> > context switches for tasks, even if, say, somehow the memory
>> > consumption
>> > remains the same).
>> >
>> > Regards,
>> > SP
>> >
>> > On Tue, Feb 20, 2024 at 10:13 PM Xiang Xiao 
>> > wrote:
>> >
>> > > Since all devices expose through vfs (/dev, /proc), udev could be
>> > > implemented through inotify API.
>> > >
>> > > On Tue, Feb 20, 2024 at 11:31 PM Alan C. Assis 
>> > wrote:
>> > >
>> > > > Hi Saurav,
>> > > >
>> > > > There is not something like a "udev" for NuttX, but there are
>> > > > daemons/services used to detect when a SDCard is plugged, when a
>> > > > USB
>> > > > device is attached, etc.
>> > > >
>> > > > We could add something like a lite "udev" for NuttX.
>> > > >
>> > > > Best Regards,
>> > > >
>> > > > Alan
>> > > >
>> > > > On 2/20/24, Saurav Pal  wrote:
>> > > > > Hi all,
>> > > > >
>> > > > > I am not able to understand how NuttX performs device discovery.
>> > > > > I
>> am
>> > > > > trying to look for something that is similar to "udev". Can
>> > > > > someone
>> > > > please
>> > > > > help me understand?
>> > > > >
>> > > > > Thanks in advance.
>> > > > > Regards,
>> > > > > SP
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: Better FPGA support on NuttX //was Re: [OT] Projects for GSoC 2024

[Alan C. Assis]

Hi Victor, thank you very much for this information and this link.

I found a nice project using that board:

https://github.com/lucysrausch/colorlight-led-cube

I remember also seeing some FPGA board to control LEDs panel that
could be used as ordinary FPGA dev tool. But I think these boards
don't have much LE internally, right?

Best Regards,

Alan

On 2/19/24, Victor Suarez Rovere  wrote:
> Reference to cheap FPGA boards (< $20) were added to the new repo, more
> docs will follow there: https://github.com/cederom/nuttx-fpga
> So, FPGA is not strictly related to $$$
>

Re: Device Discovery

[Alan C. Assis]

Hi Saurav,

There is not something like a "udev" for NuttX, but there are
daemons/services used to detect when a SDCard is plugged, when a USB
device is attached, etc.

We could add something like a lite "udev" for NuttX.

Best Regards,

Alan

On 2/20/24, Saurav Pal  wrote:
> Hi all,
>
> I am not able to understand how NuttX performs device discovery. I am
> trying to look for something that is similar to "udev". Can someone please
> help me understand?
>
> Thanks in advance.
> Regards,
> SP
>

Better FPGA support on NuttX //was Re: [OT] Projects for GSoC 2024

[Alan C. Assis]

Let's follow the discussion here to avoid polluting the previous thread.

On 2/18/24, Tomek CEDRO  wrote:
> Closed, okay, and the FPGA part did not get in?
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
> On Sun, Feb 18, 2024 at 10:17 PM Alan C. Assis  wrote:
>>
>> Hi Tomek,
>> Thank you for raising these concerns.
>>
>> BTW, I suggest you change the Subject to something related to NuttX and
>> FPGA, since the GSoC 2024 proposal is already closed (on Feb 6).
>>
>> Best Regards,
>>
>> Alan
>>
>> On Sun, Feb 18, 2024 at 4:52 PM Tomek CEDRO  wrote:
>>
>> > After some more considerations I am pro this "generic" NuttX@FPGA
>> > Reference Design on GSoC proposal, 10 resons below :-)
>> >
>> > I kindly ask to add this one to the proposals list :-)
>> >
>> > 1. We do not have a reference FPGA design for NuttX.
>> > 2. We do not have a reference fully Open-Source toolchain for
>> > FPGA+NuttX.
>> > 3. Yes someone did that before, and anyone can do that, but we can
>> > provide generic out-of-the-box solution that most people are looking
>> > for. Creating / repeating one yourself costs time.
>> > 4. We can gather smart community around NuttX that way (i.e. Victor).
>> > 5. FPGA are getting smaller and cheaper close to a price range of MCU
>> > (i.e. $5+) [1][2].
>> > 6. FPGA has big advantage over MCU in peripheral speed (mainly GPIO
>> > nMHz vs nnnMHz). I can see unique benefit for having custom
>> > peripherals created that way. I once did an R on new type of ADC
>> > where MCU GPIO was not fast enough and I have to switch to FPGA +
>> > external control MCU board.
>> > 7. Using propietary tools was quite painful because I had to use big
>> > Xilinx Vivado while there are fully Open-Source toolchains already out
>> > there we can use like Yosys / OSS CAD Suite [3] etc.
>> > 8. Scaling to bigger FPGA gives more possibilities like new
>> > architecture testing (i.e. RISC-V 128-bit or tens/hundreds of cores)
>> > [4], emulation [5], machine learning, etc.
>> > 9. My initial proposal was highly experimental and could easily fail.
>> > Victor's proposal is merit and result based. It will for sure serve
>> > many people out there for bigger and smaller projects.
>> > 10. Other ideas like Xorg port could be tested on FPGA implementation
>> > too.. I already saw Victor's working windows manager with
>> > chip-mod-player running on FPGA :-)
>> >
>> > I can be mentor of that project because I would like to grow in that
>> > field too as I have some ideas to test :-)
>> >
>> > Thanks for considering :-)
>> > Tomek
>> >
>> > [1] https://tinyfpga.com/
>> > [2]
>> > https://www.cnx-software.com/2019/10/15/5-tang-nano-fpga-board-gowin-gw1n-littlebee-fpga/
>> > [3] https://github.com/YosysHQ/oss-cad-suite-build
>> > [4]
>> > https://riscv.org/news/2021/08/esperanto-emerges-from-stealth-with-1000-core-risc-v-ai-accelerator-sally-ward-foxton-ee-times/
>> > [5] https://www.retrorgb.com/mister.html
>> >
>> > --
>> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>> >
>> > On Sat, Jan 27, 2024 at 10:58 PM Victor Suarez Rovere
>> >  wrote:
>> > >
>> > > The innovation won't be to run NuttX in a RISC-V (soft-core or not)
>> > > but
>> > > using a FPGA for its flexibility to add any kind of peripherals, one
>> > > of
>> > the
>> > > main ones to be useful in my view will be a high-resolution
>> > > framebuffer
>> > and
>> > > USB mouse/keyboard for a complete UI
>> > >
>> > > On Sat, Jan 27, 2024 at 4:31 PM Gregory Nutt 
>> > wrote:
>> > >
>> > > > Aren't most CPUs available as soft cores?  Certainly Xtensa was
>> > intended
>> > > > for that purpose.  ARM and MIPS have been common soft cores in
>> > > > ASICs
>> > for
>> > > > more than a decade. As is RISC-V soft core in FPGAs.
>> > > > https://en.wikipedia.org/wiki/Soft_microprocessor
>> > > >
>> > > > In the past, there was some interest in ports of NuttX to
>> > > > softcore's
>> > > > like MicroBlaze.  But there hasn't been that kind of interest in
>> > > > recent
>> > > > times.
>> > > >
>> > > > This would have been an innovation a decade or s

Re: [OT] Projects for GSoC 2024

[Alan C. Assis]

Hi Victor,

Yes, as I said before I also think this is a very important field, but at
least for this chinese board I realized that things are not there yet.

Maybe using a Lattice FPGA could work better, but anyway, a good FPGA board
to run a RISC-V is not too low cost.

Tang Primer 20K is lower cost, but the open-source tools are not that great.

I found a good discussion here:
https://www.reddit.com/r/RISCV/comments/z9v6f8/which_fpga_for_getting_into_riscv/

Someone suggested ULX3S as a good board to work with open-source tools, but
the board version with Lattice ECP5 85F costs more than U$ 300 on
Aliexpress.

That is not a low cost for someone that just wants to try an FPGA.

Best Regards,

Alan

On Mon, Feb 19, 2024 at 12:08 PM Victor Suarez Rovere <
suarezvic...@gmail.com> wrote:

> Hi
> I have experience doing FPGA development including graphics (micropython
> port, ImGUI port, USB mouse/keyboard etc.)
> I think the open-source tool ecosystem for FPGA development is mature
> enough not to depend on proprietary tools and IP, mainly related to Lattice
> devices but also for most Xilinx devices.
> And I fully agree with what Tomek said in every aspect with regards to the
> convenience of mailined FPGA support.
>
> Best,
> Victor.
>
>
>
> On Mon, Feb 19, 2024 at 11:50 AM Alan C. Assis  wrote:
>
> > No, as we pointed out, it is a long term project that needs to be well
> > thought out.
> >
> > You listed many possibilities, we need to define a goal and focus on it.
> >
> > Let me share my (bad) experience with FPGA:
> > Sometime ago I bought a low cost Tang Primer 20K board expecting to start
> > using open-source tools to program it (many places said it was
> supported).
> >
> > Then when I installed the software I discovered that I need to download
> the
> > proprietary SDK and copy many files from it to get things working.
> >
> > It was a show stopper for me!
> >
> > Imagine if you wanted to compile NuttX and had to download the vendor SDK
> > and copy their files to inside NuttX.
> >
> > Best Regards,
> >
> > Alan
> >
> > On Sun, Feb 18, 2024 at 8:02 PM Tomek CEDRO  wrote:
> >
> > > Closed, okay, and the FPGA part did not get in?
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
> > > On Sun, Feb 18, 2024 at 10:17 PM Alan C. Assis 
> > wrote:
> > > >
> > > > Hi Tomek,
> > > > Thank you for raising these concerns.
> > > >
> > > > BTW, I suggest you change the Subject to something related to NuttX
> and
> > > > FPGA, since the GSoC 2024 proposal is already closed (on Feb 6).
> > > >
> > > > Best Regards,
> > > >
> > > > Alan
> > > >
> > > > On Sun, Feb 18, 2024 at 4:52 PM Tomek CEDRO 
> wrote:
> > > >
> > > > > After some more considerations I am pro this "generic" NuttX@FPGA
> > > > > Reference Design on GSoC proposal, 10 resons below :-)
> > > > >
> > > > > I kindly ask to add this one to the proposals list :-)
> > > > >
> > > > > 1. We do not have a reference FPGA design for NuttX.
> > > > > 2. We do not have a reference fully Open-Source toolchain for
> > > FPGA+NuttX.
> > > > > 3. Yes someone did that before, and anyone can do that, but we can
> > > > > provide generic out-of-the-box solution that most people are
> looking
> > > > > for. Creating / repeating one yourself costs time.
> > > > > 4. We can gather smart community around NuttX that way (i.e.
> Victor).
> > > > > 5. FPGA are getting smaller and cheaper close to a price range of
> MCU
> > > > > (i.e. $5+) [1][2].
> > > > > 6. FPGA has big advantage over MCU in peripheral speed (mainly GPIO
> > > > > nMHz vs nnnMHz). I can see unique benefit for having custom
> > > > > peripherals created that way. I once did an R on new type of ADC
> > > > > where MCU GPIO was not fast enough and I have to switch to FPGA +
> > > > > external control MCU board.
> > > > > 7. Using propietary tools was quite painful because I had to use
> big
> > > > > Xilinx Vivado while there are fully Open-Source toolchains already
> > out
> > > > > there we can use like Yosys / OSS CAD Suite [3] etc.
> > > > > 8. Scaling to bigger FPGA gives more possibilities like new
> > > > > architecture testing (i.e. RISC-V 128-bit or tens/hundreds of
> cores)
> >

Re: [OT] Projects for GSoC 2024

[Alan C. Assis]

Tomek,

The list with all GSoC 2024 from Apache Foundation is here:

https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2024+Ideas+list

Until now we have two contributors interested in participating, but we
proposed 6 projects.

Best Regards,

Alan

On Sun, Feb 18, 2024 at 8:02 PM Tomek CEDRO  wrote:

> Closed, okay, and the FPGA part did not get in?
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
> On Sun, Feb 18, 2024 at 10:17 PM Alan C. Assis  wrote:
> >
> > Hi Tomek,
> > Thank you for raising these concerns.
> >
> > BTW, I suggest you change the Subject to something related to NuttX and
> > FPGA, since the GSoC 2024 proposal is already closed (on Feb 6).
> >
> > Best Regards,
> >
> > Alan
> >
> > On Sun, Feb 18, 2024 at 4:52 PM Tomek CEDRO  wrote:
> >
> > > After some more considerations I am pro this "generic" NuttX@FPGA
> > > Reference Design on GSoC proposal, 10 resons below :-)
> > >
> > > I kindly ask to add this one to the proposals list :-)
> > >
> > > 1. We do not have a reference FPGA design for NuttX.
> > > 2. We do not have a reference fully Open-Source toolchain for
> FPGA+NuttX.
> > > 3. Yes someone did that before, and anyone can do that, but we can
> > > provide generic out-of-the-box solution that most people are looking
> > > for. Creating / repeating one yourself costs time.
> > > 4. We can gather smart community around NuttX that way (i.e. Victor).
> > > 5. FPGA are getting smaller and cheaper close to a price range of MCU
> > > (i.e. $5+) [1][2].
> > > 6. FPGA has big advantage over MCU in peripheral speed (mainly GPIO
> > > nMHz vs nnnMHz). I can see unique benefit for having custom
> > > peripherals created that way. I once did an R on new type of ADC
> > > where MCU GPIO was not fast enough and I have to switch to FPGA +
> > > external control MCU board.
> > > 7. Using propietary tools was quite painful because I had to use big
> > > Xilinx Vivado while there are fully Open-Source toolchains already out
> > > there we can use like Yosys / OSS CAD Suite [3] etc.
> > > 8. Scaling to bigger FPGA gives more possibilities like new
> > > architecture testing (i.e. RISC-V 128-bit or tens/hundreds of cores)
> > > [4], emulation [5], machine learning, etc.
> > > 9. My initial proposal was highly experimental and could easily fail.
> > > Victor's proposal is merit and result based. It will for sure serve
> > > many people out there for bigger and smaller projects.
> > > 10. Other ideas like Xorg port could be tested on FPGA implementation
> > > too.. I already saw Victor's working windows manager with
> > > chip-mod-player running on FPGA :-)
> > >
> > > I can be mentor of that project because I would like to grow in that
> > > field too as I have some ideas to test :-)
> > >
> > > Thanks for considering :-)
> > > Tomek
> > >
> > > [1] https://tinyfpga.com/
> > > [2]
> > >
> https://www.cnx-software.com/2019/10/15/5-tang-nano-fpga-board-gowin-gw1n-littlebee-fpga/
> > > [3] https://github.com/YosysHQ/oss-cad-suite-build
> > > [4]
> > >
> https://riscv.org/news/2021/08/esperanto-emerges-from-stealth-with-1000-core-risc-v-ai-accelerator-sally-ward-foxton-ee-times/
> > > [5] https://www.retrorgb.com/mister.html
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
> > > On Sat, Jan 27, 2024 at 10:58 PM Victor Suarez Rovere
> > >  wrote:
> > > >
> > > > The innovation won't be to run NuttX in a RISC-V (soft-core or not)
> but
> > > > using a FPGA for its flexibility to add any kind of peripherals, one
> of
> > > the
> > > > main ones to be useful in my view will be a high-resolution
> framebuffer
> > > and
> > > > USB mouse/keyboard for a complete UI
> > > >
> > > > On Sat, Jan 27, 2024 at 4:31 PM Gregory Nutt 
> > > wrote:
> > > >
> > > > > Aren't most CPUs available as soft cores?  Certainly Xtensa was
> > > intended
> > > > > for that purpose.  ARM and MIPS have been common soft cores in
> ASICs
> > > for
> > > > > more than a decade. As is RISC-V soft core in FPGAs.
> > > > > https://en.wikipedia.org/wiki/Soft_microprocessor
> > > > >
> > > > > In the past, there was some interest in ports of NuttX to
> softcore's
> > > > > like M

Re: [OT] Projects for GSoC 2024

[Alan C. Assis]

No, as we pointed out, it is a long term project that needs to be well
thought out.

You listed many possibilities, we need to define a goal and focus on it.

Let me share my (bad) experience with FPGA:
Sometime ago I bought a low cost Tang Primer 20K board expecting to start
using open-source tools to program it (many places said it was supported).

Then when I installed the software I discovered that I need to download the
proprietary SDK and copy many files from it to get things working.

It was a show stopper for me!

Imagine if you wanted to compile NuttX and had to download the vendor SDK
and copy their files to inside NuttX.

Best Regards,

Alan

On Sun, Feb 18, 2024 at 8:02 PM Tomek CEDRO  wrote:

> Closed, okay, and the FPGA part did not get in?
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
> On Sun, Feb 18, 2024 at 10:17 PM Alan C. Assis  wrote:
> >
> > Hi Tomek,
> > Thank you for raising these concerns.
> >
> > BTW, I suggest you change the Subject to something related to NuttX and
> > FPGA, since the GSoC 2024 proposal is already closed (on Feb 6).
> >
> > Best Regards,
> >
> > Alan
> >
> > On Sun, Feb 18, 2024 at 4:52 PM Tomek CEDRO  wrote:
> >
> > > After some more considerations I am pro this "generic" NuttX@FPGA
> > > Reference Design on GSoC proposal, 10 resons below :-)
> > >
> > > I kindly ask to add this one to the proposals list :-)
> > >
> > > 1. We do not have a reference FPGA design for NuttX.
> > > 2. We do not have a reference fully Open-Source toolchain for
> FPGA+NuttX.
> > > 3. Yes someone did that before, and anyone can do that, but we can
> > > provide generic out-of-the-box solution that most people are looking
> > > for. Creating / repeating one yourself costs time.
> > > 4. We can gather smart community around NuttX that way (i.e. Victor).
> > > 5. FPGA are getting smaller and cheaper close to a price range of MCU
> > > (i.e. $5+) [1][2].
> > > 6. FPGA has big advantage over MCU in peripheral speed (mainly GPIO
> > > nMHz vs nnnMHz). I can see unique benefit for having custom
> > > peripherals created that way. I once did an R on new type of ADC
> > > where MCU GPIO was not fast enough and I have to switch to FPGA +
> > > external control MCU board.
> > > 7. Using propietary tools was quite painful because I had to use big
> > > Xilinx Vivado while there are fully Open-Source toolchains already out
> > > there we can use like Yosys / OSS CAD Suite [3] etc.
> > > 8. Scaling to bigger FPGA gives more possibilities like new
> > > architecture testing (i.e. RISC-V 128-bit or tens/hundreds of cores)
> > > [4], emulation [5], machine learning, etc.
> > > 9. My initial proposal was highly experimental and could easily fail.
> > > Victor's proposal is merit and result based. It will for sure serve
> > > many people out there for bigger and smaller projects.
> > > 10. Other ideas like Xorg port could be tested on FPGA implementation
> > > too.. I already saw Victor's working windows manager with
> > > chip-mod-player running on FPGA :-)
> > >
> > > I can be mentor of that project because I would like to grow in that
> > > field too as I have some ideas to test :-)
> > >
> > > Thanks for considering :-)
> > > Tomek
> > >
> > > [1] https://tinyfpga.com/
> > > [2]
> > >
> https://www.cnx-software.com/2019/10/15/5-tang-nano-fpga-board-gowin-gw1n-littlebee-fpga/
> > > [3] https://github.com/YosysHQ/oss-cad-suite-build
> > > [4]
> > >
> https://riscv.org/news/2021/08/esperanto-emerges-from-stealth-with-1000-core-risc-v-ai-accelerator-sally-ward-foxton-ee-times/
> > > [5] https://www.retrorgb.com/mister.html
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
> > > On Sat, Jan 27, 2024 at 10:58 PM Victor Suarez Rovere
> > >  wrote:
> > > >
> > > > The innovation won't be to run NuttX in a RISC-V (soft-core or not)
> but
> > > > using a FPGA for its flexibility to add any kind of peripherals, one
> of
> > > the
> > > > main ones to be useful in my view will be a high-resolution
> framebuffer
> > > and
> > > > USB mouse/keyboard for a complete UI
> > > >
> > > > On Sat, Jan 27, 2024 at 4:31 PM Gregory Nutt 
> > > wrote:
> > > >
> > > > > Aren't most CPUs available as soft cores?  Certainly Xtensa was
> > > intended
> > > > > for tha

Re: [OT] Projects for GSoC 2024

[Alan C. Assis]

n3sr3VMJQU
> > > >>
> > > >> --
> > > >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > >>
> > > >> On Sat, Jan 27, 2024 at 7:22 AM Victor Suarez Rovere
> > > >>  wrote:
> > > >>> Just clarifying, the idea to run NuttX on a FPGA is to instantiate
> a
> > > CPU
> > > >>> and peripherals on the FPGA and then run normally as if it were a
> MCU
> > > >>> Good thing is that you can change the CPU, add/remove peripherals,
> etc.
> > > >>>
> > > >>> On Sat, Jan 27, 2024 at 12:32 AM Tomek CEDRO 
> wrote:
> > > >>>
> > > >>>> Hey there Victor! Thanks for your interest in NuttX port to
> FPGA!! :-)
> > > >>>>
> > > >>>> No there is no such design yet.. you would have to create
> everything
> > > >>>> from scratch.. so there is some serious amount of work to do.. but
> > > >>>> imagine the results.. there will be just one step to ASIC!! :-)
> > > >>>>
> > > >>>> I could  reconsider my mentor position in this kind of project
> because
> > > >>>> I would really love to see the internals first hand.. with a help
> of
> > > >>>> more experienced NuttX'er for sure as second mentor :-) :-)
> > > >>>>
> > > >>>> I did a PONG on FPGA over 10 years ago but I would never dare to
> run
> > > >>>> CPU-less-program directly on FPGA.. then RTOS.. then lets say
> Atari
> > > >>>> emulator.. chip module player.. open source smart debug probe.. a
> > > >>>> neural interface.. who knows.. would that even fit into the FPGA?
> :-)
> > > >>>> :-)
> > > >>>>
> > > >>>> I have a strong feeling this may be important.. but I leave the
> whole
> > > >>>> decision to the PMC :-)
> > > >>>>
> > > >>>> Have a good weekend my friends :-)
> > > >>>> Tomek
> > > >>>>
> > > >>>> --
> > > >>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > >>>>
> > > >>>> On Sat, Jan 27, 2024 at 2:55 AM Victor Suarez Rovere
> > > >>>>  wrote:
> > > >>>>> I can certainly port NuttX to run on some FPGA boards too
> > > >>>>> Is any board already supported?
> > > >>>>>
> > > >>>>> On Fri, Jan 26, 2024 at 4:40 PM Alan C. Assis  >
> > > >> wrote:
> > > >>>>>> Hi Tomek,
> > > >>>>>>
> > > >>>>>> His toolchain is focused on FPGA, but he is interested in
> > > >>>> participating in
> > > >>>>>> other projects for GSoC.
> > > >>>>>>
> > > >>>>>> Also we need NuttX mentors, I will participate, but for each
> > > >> project we
> > > >>>>>> need two mentors, please let me know who could be interested to
> > > >> help.
> > > >>>>>> Best Regards,
> > > >>>>>>
> > > >>>>>> Alan
> > > >>>>>>
> > > >>>>>> On Fri, Jan 26, 2024 at 3:33 PM Tomek CEDRO 
> > > >> wrote:
> > > >>>>>>> On Fri, Jan 26, 2024 at 2:07 PM Alan C. Assis wrote:
> > > >>>>>>>> Dear NuttXers,
> > > >>>>>>>> Please find below some ideas of projects to improve NuttX
> > > >> during
> > > >>>> the
> > > >>>>>>>> GSoC2024:
> > > >>>>>>>>
> > > >>
> https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2024+Ideas+list
> > > >>>>>>>> If you have some other ideas, please let me know.
> > > >>>>>>> I would like to propose Victor Suarez (CC) idea for porting
> > > >> toolchain
> > > >>>>>>> NuttX RTOS directly to FPGA :-)
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>
> > >
> https://www.tomshardware.com/news/fpga-demo-shows-efficiency-gains-compared-to-x86-chip
> > > >>>>>>> Tomek
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > >>>>>>>
> > >
> > >
>

Re: Addition of New Chip STM32F427AI

[Alan C. Assis]

Hi,

Let me show something "magic" :

$ cd nuttx/arch/arm/src/stm32/hardware/
$ git grep STM32F427

Now you have super power!!! ;-)

Best Regards,

Alan

On Wed, Feb 14, 2024 at 2:25 AM Janardhan Silwal <
janardhansil...@outlook.com> wrote:

> I looked into the folder "arch/arm/src/stm32/hardware" there does not seem
> to be specific definition files for STM32F427. Any idea where the
> definitions for the F427 family is defined.
> I could then move on to add support for the unsupported features of
> STM32F427AI.
>
> Thanks
> Janardhan Silwal
>
> 
> From: Gregory Nutt 
> Sent: Tuesday, February 13, 2024 02:37
> To: dev@nuttx.apache.org 
> Subject: Re: Addition of New Chip STM32F427AI
>
> The STM32F427AI is in the same family as STM32F427xx (STM32F427V,
> STM32F427Z, STM32F427I) and STM32F429xx, which are already supported.
>
> The first thing to do is to decide which is of the supported parts is
> most like the STM32F427AI.  Mostly likely it is just a difference in
> memory size or something similar.
>
> The package STM32F427AI has more pins so some other functionality must
> be brought out.
>
> On 2/12/2024 2:06 PM, Alan C. Assis wrote:
> > Hi Janardhan,
> >
> > You can start looking at which STM32F4xx chip existent on NuttX is more
> > similar to STM32F427AI and start your port based on it.
> >
> > You can do it using the chip datasheet and/or reference manual, writing
> > down the difference in peripherals, registers, etc.
> >
> > Normally STM32 devices share many features, but sometimes they have small
> > incompatibilities.
> >
> > So, look the existing chips on NuttX (nuttx/arch/arm/src/stm32/hardware/
> > and nuttx/arch/arm/include/stm32/
> >
> > Best Regards,
> >
> > Alan
> >
> > On Mon, Feb 12, 2024 at 8:50 AM Janardhan Silwal <
> > janardhansil...@outlook.com> wrote:
> >
> >> Hi Community,
> >>
> >> I have a board which uses STM32F427AI, and was planning on running a
> >> middleware which runs over nuttx, but only noticed, after the board
> arrived
> >> from manufacturing that there is no option to select, STM32F427AI from
> the
> >> menuconfig/qconfig.
> >>
> >> I don't have an option to replace the chip to the ones which are
> currently
> >> supported and thus, want to add  the support for STM32F427AI, but don't
> >> know where to start.
> >>
> >> Hoping to get some direction, from where I can start.
> >>
> >> Thanks in advance.
> >> janardhan
> >>
>

Re: Detecting FS

[Alan C. Assis]

Hi Saurav,

Please take a look at "static const struct fsmap_t g_bdfsmap[]" in the file
nuttx/fs/mount/fs_mount.c

You will figure-out how the "magic" happens.

Best Regards,

Alan

On Mon, Feb 12, 2024 at 9:20 AM Saurav Pal  wrote:

> Hi all,
>
> I am trying to write some docs for VFS in NuttX, but there's one thing I've
> been stumbling on for some time.
>
> How are the file systems detected from the storage devices? For example, if
> I have a storage device which has been formatted using VFAT...after (say)
> power on, how does NuttX detect that vfat was used to format the storage
> device?
>
> From what I can see, NuttX does not have a "superblock" concept explicitly
> defined, nor does it seem to require the file systems to store magic
> numbers in the disk in any way.
>
> Thanks in advance.
> Regards,
> SP
>

Re: Addition of New Chip STM32F427AI

[Alan C. Assis]

Hi Janardhan,

You can start looking at which STM32F4xx chip existent on NuttX is more
similar to STM32F427AI and start your port based on it.

You can do it using the chip datasheet and/or reference manual, writing
down the difference in peripherals, registers, etc.

Normally STM32 devices share many features, but sometimes they have small
incompatibilities.

So, look the existing chips on NuttX (nuttx/arch/arm/src/stm32/hardware/
and nuttx/arch/arm/include/stm32/

Best Regards,

Alan

On Mon, Feb 12, 2024 at 8:50 AM Janardhan Silwal <
janardhansil...@outlook.com> wrote:

> Hi Community,
>
> I have a board which uses STM32F427AI, and was planning on running a
> middleware which runs over nuttx, but only noticed, after the board arrived
> from manufacturing that there is no option to select, STM32F427AI from the
> menuconfig/qconfig.
>
> I don't have an option to replace the chip to the ones which are currently
> supported and thus, want to add  the support for STM32F427AI, but don't
> know where to start.
>
> Hoping to get some direction, from where I can start.
>
> Thanks in advance.
> janardhan
>

Re: NuttX correct version

[Alan C. Assis]

Hi Roberto,

I think it is happening because we released the version 12.4.0 and forgot
to great the tag, see the git tag result:
...
nuttx-12.2.1
nuttx-12.2.1-RC0
nuttx-12.3.0
nuttx-12.3.0-RC0
nuttx-12.3.0-RC1
nuttx-12.4.0-RC0

It needs to be fixed.

BR,

Alan

On Thu, Feb 8, 2024 at 4:57 AM Roberto Bucher 
wrote:

> Hi
>
> When I create a library export of the NuttX project I receive a library
> *nuttx-export-12.4.0-RC0.tar.gz*. Is this correct or I have to get a
> *12.4.0* version?
>
> Thanks in advance
>
> Roberto
>
>
>

Re: STM32H7 board with ethernet

[Alan C. Assis]

Hi Simon,

I just sent to your email a board config example with Ethernet support for
a custom board based on stm32h745i-disco and with Ethernet support.

Probably your config is not working because there is no STM32H743ZI2 config
with ETHERNET enabled in the mainline.

Besides ETH configuration you need to check if PHY is correct.

BR,

Alan

On Tue, Feb 6, 2024 at 8:41 AM Simon Filgis 
wrote:

> Dear all,
>
> I found a STM32H743ZI2 and build the jumbo config.
>
> I have nsh access. Now I would like to setup ethernet, but it seems not
> working out of the box.
>
> nsh> ifconfig eth0 192.168.1.5
> nsh> ping any target does not work
>
> Also from my host, I cannot ping. Telnet-connection is unavailable...
>
> Do I need to enable something?
>
> Regards,
>
> Simon
>
>
> --
> Hard- and Softwaredevelopment Consultant
> Ingenieurbüro-Filgis
> USt-IdNr.: DE305343278
>
>
> On Tue, Feb 6, 2024 at 12:30 PM Roberto Bucher <
> roberto.bucher.2...@gmail.com> wrote:
>
> > The STM32H743ZI2 is quite complete. We used it with pysimCoder (ADC,
> > encoders, PWM, digital I/O, network, but not CAN bus yet)
> >
> > Roberto
> >
> > On 2/6/24 11:57, Alan C. Assis wrote:
> > > stm32h745i-disco is a great option! Ethernet and LCD
> > >
> > > On Tuesday, February 6, 2024, Simon Filgis <
> > si...@ingenieurbuero-filgis.de>
> > > wrote:
> > >
> > >> Dear all,
> > >>
> > >> Can anybody recommend a stm32h7 board with ethernet that is well
> > supported
> > >> by nuttx?
> > >>
> > >> Thanks in advance,
> > >>
> > >> Simon
> > >>
> >
> >
>

Re: STM32H7 board with ethernet

[Alan C. Assis]

stm32h745i-disco is a great option! Ethernet and LCD

On Tuesday, February 6, 2024, Simon Filgis 
wrote:

> Dear all,
>
> Can anybody recommend a stm32h7 board with ethernet that is well supported
> by nuttx?
>
> Thanks in advance,
>
> Simon
>

Re: [Article] Build & Test NuttX Apps in the Web Browser (TCC RISC-V Compiler)

[Alan C. Assis]

Hi Lup,

Congratulations! That was a great achievement!!!

It would be nice if we could get TCC integrated on apps/ to run inside MCUs
with much memory (like STM32 with external SDRAM), ESP32, BL808, etc.

Best Regards,

Alan

On Sat, Feb 3, 2024 at 8:08 PM Lee, Lup Yuen  wrote:

> Today we're running NuttX Emulator inside a Web Browser. What if we could
> build and test NuttX Apps in the Web Browser? Learning NuttX becomes so
> cool!
>
> Let's explore with TCC (Tiny C Compiler) for 64-bit RISC-V, compiled to
> WebAssembly with Zig Compiler...
>
> (1) Zig Compiler compiles TCC Compiler to WebAssembly (with one tiny fix)
> (2) But we hit some Missing POSIX Functions
> (3) So we built minimal File Input and Output
> (4) Hacked up a simple workaround for fprintf and friends
> (5) And TCC produces a RISC-V Binary that runs on NuttX Emulator, in the
> Web Browser!
> (6) Though it needs Low-Level NuttX System Calls. We might fix this by
> porting NuttX ROM FS to Zig and WebAssembly.
>
> Here's the article: https://lupyuen.codeberg.page/articles/tcc.html
>
> Lup
>

Re: FAT macro

[Alan C. Assis]

Hi Saurav,

You can follow the steps here:
https://nuttx.apache.org/docs/latest/contributing/index.html

After running the checkpatch.sh and confirming everything is fine, you can
create a commit.

Basically your commit should be like this:

--
fs/vfat: Fix typo in the macro DIRSEC_BYTENDX

Some comments explaining what the commit is supposed to do!

Signed-off-by: Saurav Pal 
--

Best Regards,

Alan

On Fri, Feb 2, 2024 at 5:14 PM Saurav Pal  wrote:

> Hi Alan,
>
> Yeah I'll add an issue in the repo, and put a PR for fixing this. A quick
> question...is there any standard on commit names, or should I just use my
> own like "FIX: VFAT macro Issue#123"?
>
> About why side effects have not been seen...like Lwazi explained,
> macro DIRSEC_BYTENDX(f,
> i) is always used as DIRSEC_BYTENDX(fs, inode), and so, in its expansion,
> DIRSEC_NDXMASK(f) should become DIRSEC_NDXMASK(fs), and that weirdly
> coincides with what the typo is, and so, it weirdly works how it was
> intended to and does not give any errors.
>
> Since it is a macro, even language servers (as far as the ones I know) do
> not visually show their "unused parameters" warning like in the case proper
> functions.
>
> Regards,
> Saurav
>
> On Sat, Feb 3, 2024 at 1:11 AM Alan C. Assis  wrote:
>
> > Hi Saurav,
> >
> > I think you found a BUG!
> >
> > Please report it at https://github.com/apache/nuttx/issues to keep a
> track
> > of it and when you we submit a PR it could be closed automatically (since
> > you link it at your PR).
> >
> > In fact looking both macros the f to fs mistake becomes clear:
> >
> > #define DIRSEC_NDXMASK(f)   (((f)->fs_hwsectorsize - 1) >> 5)
> >
> > #define DIRSEC_BYTENDX(f,i) (((i) & DIRSEC_NDXMASK(fs)) << 5)
> >
> > I'm curious to know what this mistake could cause to VFAT on NuttX?
> >
> > Why haven't we seen any side effects in products using NuttX with VFAT?
> >
> > Best Regards,
> >
> > Alan
> >
> > On Fri, Feb 2, 2024 at 1:55 PM Saurav Pal  wrote:
> >
> > > Hi Alan,
> > >
> > > Thank you for looking at our code base and planning to add
> Documentation,
> > > > that is really important!
> > > >
> > > > NuttX has a long history but our Documentation is still lagging
> behind,
> > > so
> > > > your work will be very beneficial for our community.
> > > >
> > >
> > > I'll try my best to contribute some documentation for the various file
> > > systems I look into, and I, in turn, hope they are informative, and
> more
> > > importantly, correct, as I'm pretty new to the VFS layer of NuttX.
> > >
> > >
> > > > BTW, why do you think it is wrong, could you please share your
> > thoughts?
> > > >
> > >
> > > The problem according to me is on L264...where it's defined as:
> > >
> > > #define DIRSEC_BYTENDX(*f*,i) (((i) & DIRSEC_NDXMASK(*fs*)) << 5)
> > >
> > > I can't seem to find anything defined as *fs *in the namespace at that
> > > point (used in the fat_findsfnentry
> > > <
> >
> https://github.com/apache/nuttx/blob/master/fs/fat/fs_fat32dirent.c#L1137
> > > >function),
> > > and I was wondering if it was a simple typo or a mistake on my part as
> > it's
> > > code that's quite old, which usually don't have such mistakes due to
> > > extensive testing.
> > >
> > > Best Regards,
> > > Saurav
> > >
> >
>

Re: FAT macro

[Alan C. Assis]

Hi Saurav,

I think you found a BUG!

Please report it at https://github.com/apache/nuttx/issues to keep a track
of it and when you we submit a PR it could be closed automatically (since
you link it at your PR).

In fact looking both macros the f to fs mistake becomes clear:

#define DIRSEC_NDXMASK(f)   (((f)->fs_hwsectorsize - 1) >> 5)

#define DIRSEC_BYTENDX(f,i) (((i) & DIRSEC_NDXMASK(fs)) << 5)

I'm curious to know what this mistake could cause to VFAT on NuttX?

Why haven't we seen any side effects in products using NuttX with VFAT?

Best Regards,

Alan

On Fri, Feb 2, 2024 at 1:55 PM Saurav Pal  wrote:

> Hi Alan,
>
> Thank you for looking at our code base and planning to add Documentation,
> > that is really important!
> >
> > NuttX has a long history but our Documentation is still lagging behind,
> so
> > your work will be very beneficial for our community.
> >
>
> I'll try my best to contribute some documentation for the various file
> systems I look into, and I, in turn, hope they are informative, and more
> importantly, correct, as I'm pretty new to the VFS layer of NuttX.
>
>
> > BTW, why do you think it is wrong, could you please share your thoughts?
> >
>
> The problem according to me is on L264...where it's defined as:
>
> #define DIRSEC_BYTENDX(*f*,i) (((i) & DIRSEC_NDXMASK(*fs*)) << 5)
>
> I can't seem to find anything defined as *fs *in the namespace at that
> point (used in the fat_findsfnentry
>  >function),
> and I was wondering if it was a simple typo or a mistake on my part as it's
> code that's quite old, which usually don't have such mistakes due to
> extensive testing.
>
> Best Regards,
> Saurav
>

Re: FAT macro

[Alan C. Assis]

Hi Saurav,

Thank you for looking at our code base and planning to add Documentation,
that is really important!

NuttX has a long history but our Documentation is still lagging behind, so
your work will be very beneficial for our community.

I took a look at that macro you asked and seems it was wrote by Greg almost
16 years ago:

08d439fefbd (patacongo  2008-08-02 14:44:25 +  262) #define
DIRSEC_NDXMASK(f)   (((f)->fs_hwsectorsize - 1) >> 5)

BTW, why do you think it is wrong, could you please share your thoughts?

Best Regards,

Alan

On Fri, Feb 2, 2024 at 3:50 AM Saurav Pal  wrote:

> Hi,
>
> I was browsing through the source code of FAT implementation, trying to
> write some documentation, and I came across this macro
> .
>
> Since I'm new to the codebase, I wanted to know if this (especially
> DIRSEC_NDXMASK(fs)) is correct and I'm missing something or if it should
> have been DIRSEC_NDXMASK(f) (and I can raise an issue for it).
>
> Thanks and regards,
> Saurav
>

Re: [OT] Projects for GSoC 2024

[Alan C. Assis]

Hi Tomek,

Thank you for raising these good points and thank YF for suggesting it.

I also don't know much details about it, maybe I think at list on Linux we
have some other libs working between X11 and Wayland to make "legacy" code
work correctly.

I'm CC Nicolas Caramelli who recently added support to DirectFB2 (
https://github.com/directfb2/DirectFB2) on NuttX, maybe (or maybe not) he
could help us to get a better vision of it.

Another advantage when thinking about X11 port to NuttX is because
nanox/microwindows is an implementation that does exactly that.

Also keep in mind that what RT-Thread did was just add support to use
weston in the host, something NuttX has more than 3 years ago and works on
X11 and Wayland.

Their weston port (AFAIK) doesn't support any embedded board directly.

BR,

Alan

On Fri, Feb 2, 2024 at 1:35 AM Tomek CEDRO  wrote:

> On Fri, Feb 2, 2024 at 1:42 AM yfliu2008 wrote:
> > How about adding Wayland instead of X11? It seems RT-Thread can run
> weston now.
>
> * Wayland is basically a framebuffer.
> * What are advantages of Wayland over X11 here?
> * How would that support porting known libraries and applications to NuttX?
> * What would be estimated workload and result?
> * Would you like to port Wayland to NuttX?
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: NuttX Workshop 2024 - event planning

[Alan C. Assis]

Good question Greg!

I think it is this way for legal reasons: this is not an event released or
promoted by Apache Software Foundation (ASF).

And although the official name of the project is Apache NuttX, we can't use
the Apache NuttX Workshop, because that would emphasize an Apache event,
but it is a community driven event.

Maybe in the future this event could be driven by ASF, like Linux
Foundation does.

Best Regards,

Alan

On Mon, Jan 29, 2024 at 10:30 AM Gregory Nutt  wrote:

> Shouldn't this be "Apache NuttX Workshop 2024" instead of "Nuttx
> Workshop 2024".  Apache NuttX is the full, legal name of the RTOS; Use
> of NuttX alone is considered ambiguous and is discouraged by the ASF.
>
>
>

Re: [Article] NuttX on Ox64 BL808: Automated Testing with Ox64 Emulator

[Alan C. Assis]

Hi Lup,

That is a great idea!

Maybe we could have a Raspberry Pi or other low cost / low power board
running locally and submitting a report to our CI or other Q page.

BR,

Alan

On Sat, Jan 27, 2024 at 10:23 PM Lee, Lup Yuen  wrote:

> << I think it could be very useful if integrated with CI. We could find
> many issues that aren't detected currently. >>
>
> Thanks Alan, that's a great idea! Lemme find the best way to integrate
> Automated Testing into the CI, without breaking our PR Submissions.
>
> If a PR breaks the CI: Maybe we can run an "Auto Triage" to guess the
> Severity of the Breakage? Like:
> (1) Code Red: "Most likely the PR Code broke the CI, please fix the PR"
> (2) Code Amber: "Maybe the PR Code broke the CI? Needs more investigation"
> (3) Code Green: "Probably OK" (e.g. unable to download OpenAMP, automated
> test failed)
>
> Right now I'm running the Automated Test every morning (GMT+8). So I have
> the rest of the day to figure out what broke, without staying up all night
> :-)
>
> Lup
>
> On Sun, Jan 28, 2024 at 7:36 AM Alan C. Assis  wrote:
>
> > Hi Lup,
> >
> > Congratulations, I think it could be very useful if integrated with CI.
> >
> > We could find many issues that aren't detected currently.
> >
> > Best Regards,
> >
> > Alan
> >
> > On Sat, Jan 27, 2024 at 8:05 PM Lee, Lup Yuen  wrote:
> >
> > > Every day we’re auto-building NuttX for Ox64 BL808 RISC-V SBC... Can we
> > > test NuttX on Ox64 automatically after building?
> > >
> > > Yes we can! With a little help from the Ox64 BL808 Emulator that we
> > created
> > > last week. In this article, we fill in the missing pieces of our Ox64
> > > Emulator and run it for Automated Testing...
> > >
> > > (1) Booting NuttX in Supervisor Mode (instead of Machine Mode)
> > > (2) Emulate OpenSBI for setting the System Timer
> > > (3) Emulate the UART Interrupts for Console Input
> > > (4) Execute everything with Expect Scripting (based on TCL)
> > > (5) Which becomes our Daily Automated Testing (triggered every day by
> > > GitHub Actions)
> > >
> > > Here's the article:
> https://lupyuen.codeberg.page/articles/tinyemu3.html
> > >
> > > Lup
> > >
> >
>

Re: [Article] NuttX on Ox64 BL808: Automated Testing with Ox64 Emulator

[Alan C. Assis]

Hi Lup,

Congratulations, I think it could be very useful if integrated with CI.

We could find many issues that aren't detected currently.

Best Regards,

Alan

On Sat, Jan 27, 2024 at 8:05 PM Lee, Lup Yuen  wrote:

> Every day we’re auto-building NuttX for Ox64 BL808 RISC-V SBC... Can we
> test NuttX on Ox64 automatically after building?
>
> Yes we can! With a little help from the Ox64 BL808 Emulator that we created
> last week. In this article, we fill in the missing pieces of our Ox64
> Emulator and run it for Automated Testing...
>
> (1) Booting NuttX in Supervisor Mode (instead of Machine Mode)
> (2) Emulate OpenSBI for setting the System Timer
> (3) Emulate the UART Interrupts for Console Input
> (4) Execute everything with Expect Scripting (based on TCL)
> (5) Which becomes our Daily Automated Testing (triggered every day by
> GitHub Actions)
>
> Here's the article: https://lupyuen.codeberg.page/articles/tinyemu3.html
>
> Lup
>

Re: [OT] Projects for GSoC 2024

[Alan C. Assis]

Hi Tomek,

AFAIK, compiling the NuttX to run inside an FPGA is not a kind of task to
be done in a GSoC project, it should be a long term effort (if John Keynes
allows us).

Also keep in mind that currently NuttX RTOS is supposed to run on top of a
processing unit (Microcontroller, Microprocessor, etc), it is not a simple
state machine that can be emulated easily in FPGA.
So, it should be something completely different. But of course, maybe there
are some shortcuts that I'm not aware of.

BTW, Victor is also interested in participating in other projects that are
related to other areas of interest (i.e. Graphics, like X11 support to let
NuttX run Unix/Linux graphics applications).

Best Regards,

Alan


On Sat, Jan 27, 2024 at 1:23 PM Tomek CEDRO  wrote:

> Okay Victor, I was thinking about toolchain that you present in
> "Sphery vs. Shapes" [1] to be adopted for NuttX on FPGA conversion
> without a CPU design.. could you please send your full detailed
> proposal then? :-)
>
> [1] https://www.youtube.com/watch?v=hn3sr3VMJQU
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
> On Sat, Jan 27, 2024 at 7:22 AM Victor Suarez Rovere
>  wrote:
> >
> > Just clarifying, the idea to run NuttX on a FPGA is to instantiate a CPU
> > and peripherals on the FPGA and then run normally as if it were a MCU
> > Good thing is that you can change the CPU, add/remove peripherals, etc.
> >
> > On Sat, Jan 27, 2024 at 12:32 AM Tomek CEDRO  wrote:
> >
> > > Hey there Victor! Thanks for your interest in NuttX port to FPGA!! :-)
> > >
> > > No there is no such design yet.. you would have to create everything
> > > from scratch.. so there is some serious amount of work to do.. but
> > > imagine the results.. there will be just one step to ASIC!! :-)
> > >
> > > I could  reconsider my mentor position in this kind of project because
> > > I would really love to see the internals first hand.. with a help of
> > > more experienced NuttX'er for sure as second mentor :-) :-)
> > >
> > > I did a PONG on FPGA over 10 years ago but I would never dare to run
> > > CPU-less-program directly on FPGA.. then RTOS.. then lets say Atari
> > > emulator.. chip module player.. open source smart debug probe.. a
> > > neural interface.. who knows.. would that even fit into the FPGA? :-)
> > > :-)
> > >
> > > I have a strong feeling this may be important.. but I leave the whole
> > > decision to the PMC :-)
> > >
> > > Have a good weekend my friends :-)
> > > Tomek
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
> > > On Sat, Jan 27, 2024 at 2:55 AM Victor Suarez Rovere
> > >  wrote:
> > > >
> > > > I can certainly port NuttX to run on some FPGA boards too
> > > > Is any board already supported?
> > > >
> > > > On Fri, Jan 26, 2024 at 4:40 PM Alan C. Assis 
> wrote:
> > > >
> > > > > Hi Tomek,
> > > > >
> > > > > His toolchain is focused on FPGA, but he is interested in
> > > participating in
> > > > > other projects for GSoC.
> > > > >
> > > > > Also we need NuttX mentors, I will participate, but for each
> project we
> > > > > need two mentors, please let me know who could be interested to
> help.
> > > > >
> > > > > Best Regards,
> > > > >
> > > > > Alan
> > > > >
> > > > > On Fri, Jan 26, 2024 at 3:33 PM Tomek CEDRO 
> wrote:
> > > > >
> > > > > > On Fri, Jan 26, 2024 at 2:07 PM Alan C. Assis wrote:
> > > > > > > Dear NuttXers,
> > > > > > > Please find below some ideas of projects to improve NuttX
> during
> > > the
> > > > > > > GSoC2024:
> > > > > > >
> > > > >
> > >
> https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2024+Ideas+list
> > > > > > > If you have some other ideas, please let me know.
> > > > > >
> > > > > > I would like to propose Victor Suarez (CC) idea for porting
> toolchain
> > > > > > NuttX RTOS directly to FPGA :-)
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > >
> https://www.tomshardware.com/news/fpga-demo-shows-efficiency-gains-compared-to-x86-chip
> > > > > >
> > > > > > Tomek
> > > > > >
> > > > > > --
> > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > >
> > > > >
> > >
>

Re: [OT] Projects for GSoC 2024

[Alan C. Assis]

Hi Tomek,

His toolchain is focused on FPGA, but he is interested in participating in
other projects for GSoC.

Also we need NuttX mentors, I will participate, but for each project we
need two mentors, please let me know who could be interested to help.

Best Regards,

Alan

On Fri, Jan 26, 2024 at 3:33 PM Tomek CEDRO  wrote:

> On Fri, Jan 26, 2024 at 2:07 PM Alan C. Assis wrote:
> > Dear NuttXers,
> > Please find below some ideas of projects to improve NuttX during the
> > GSoC2024:
> > https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2024+Ideas+list
> > If you have some other ideas, please let me know.
>
> I would like to propose Victor Suarez (CC) idea for porting toolchain
> NuttX RTOS directly to FPGA :-)
>
>
> https://www.tomshardware.com/news/fpga-demo-shows-efficiency-gains-compared-to-x86-chip
>
> Tomek
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

[OT] Projects for GSoC 2024

[Alan C. Assis]

Dear NuttXers,

Please find below some ideas of projects to improve NuttX during the
GSoC2024:

https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2024+Ideas+list

If you have some other ideas, please let me know.

Best Regards,

Alan

Re: Builtin app with its own command processor on stdin

[Alan C. Assis]

Hi Jernej,
by not returning to NSH do you mean after pressing Ctrl+C ?

Maybe this tutorial will help:
https://www.youtube.com/watch?v=hszt15lTsnA

BR,

Alan

On Tue, Jan 23, 2024 at 4:56 PM Jernej Turnsek 
wrote:

> I am running an app in the foreground. I didn't have waitpid enabled. Now I
> have and it works as it should.
> BTW, my app is not exiting to nsh. Thanks.
>
> On Tue, Jan 23, 2024 at 7:38 PM Gregory Nutt  wrote:
>
> > Are you running app in foreground or background from NSH, i.e.,
> >
> > nsh> app
> > nsh> app &
> >
> > The second should show this kind of interleaved behavior.  In the first,
> > nsh should block until the app exits.
> >
> > Do you have waitpid() enabled?  The first behavior depends on the
> > availability of waitpid()
> >
> > Does you app exit and return to nsh after each command?
> >
> > On 1/23/2024 11:19 AM, Jernej Turnsek wrote:
> > > Hi,
> > > I would like to develop my own builtin application to process some
> custom
> > > commands. This app is started from nsh over the serial console. I have
> > > duplicated the code from ftpc example and when application is started
> it
> > > start to process stdin for commands. But this functionality is mixed
> with
> > > nsh own processing of commands, thus when I hit Enter, I get app> line,
> > > when hit Enter again I get nsh> command line. Entering commands like
> > > "help", I get hl on nsh and ep on my app command processor. I am
> confused
> > > here. I did not test ftpc example, but I presume it is not working
> > either.
> > > Both apps are using readline_stream API for getting the commands.
> > >
> > > Regards,
> > > Jernej
> > >
> >
> >
>

Re: NuttX Workshop 2024 - event planning

[Alan C. Assis]

Hi Alin,

I used Google Flights to comparece prices and the values are basically the
same from May to August.

If we have some bigger embedded/computer conference happening in Japan
around that time, we could put NuttX Workshop just after that, this way
people could participate in both events.

Let us define the date soon to give people enough time to submit proposals
and organize the flight.

For the Internet, while visiting my company in Canada I discovered
something very useful: install Airalo app and buy an eSIM with a low cost
Internet plan.
For Japan they have the lowest plan of 1GB data valid for 7 days for just
U$ 4.50 or 10GB valid for 30 days for U$ 9.00.

Best Regards,

Alan

Re: [Article] NuttX on Ox64 BL808 RISC-V SBC: Emulated in the Web Browser

[Alan C. Assis]

Really cool Lup! Kudos!!!

Actually booting NuttX from a floppy drive should be really nice too.

BR,

Alan

On Sat, Jan 20, 2024 at 8:43 PM Lee, Lup Yuen  wrote:

> In olden times we had Computer Games (plus Operating Systems) on 5.25-inch
> Floppy Disks. And we’d boot the Floppy Disks (clackety-clack) on Apple II
> Computers with 64 KB RAM.
>
> Today (40 years later) we boot microSD Cards (clickety-click) on Ox64 BL808
> RISC-V Single-Board Computers with 64 MB RAM.
>
> What if we could turn it into a Virtual Ox64 SBC that boots in our Web
> Browser? Exactly like an Emulated Apple II!
>
> In this article we…
> (1) Take NuttX precompiled for Ox64 (Without any modifications)
> (2) Boot it on the TinyEMU RISC-V Emulator
> (3) Create our own Emulator for Ox64 SBC (With minor tweaks to TinyEMU)
> (4) And run everything in our Web Browser (Thanks to WebAssembly)
>
> Here's the article: https://lupyuen.codeberg.page/articles/tinyemu2.html
>
> Lup
>

Re: Addition of STM32H7 MCU's

[Alan C. Assis]

Hi Kian,

All the steps are documented here:
https://nuttx.apache.org/docs/12.3.0/contributing/index.html

If you face some issue, please let me know.

BR,

Alan

On Thu, Jan 18, 2024 at 10:14 AM Kian Karas (KK)  wrote:

> Hi Robert, Community
>
> We have NuttX running on an STM32H723VE, but haven't tested all
> peripherals. We also did some initial work on an STM32H730, but this has
> hardly been tested.
>
> What is the best way to share the STM32H723VE support with the community?
> It needs some reviewing. I am concerned we could have broken stuff for
> other MCUs in the familly, but I can't test this.
>
> @Robert: if you are in a hurry, send me an email directly and I'll respond
> with a patch.
>
> Regards
> Kian
> 
> From: Robert Turner 
> Sent: 18 January 2024 03:30
> To: dev@nuttx.apache.org 
> Subject: Re: Addition of STM32H7 MCU's
>
> Nah not internal cache. The SRAM sizes for H723/5 are different from any of
> those defined in arch/arm/include/stm32h7/chip.h
> Suspect we need to get these correct as other files use these defs also,
> such as stm32_allocateheap.c
> Is Jorge's PR the one merged on Jul 12 (8ceff0d)?
> Thanks,
> Robert
>
> On Thu, Jan 18, 2024 at 2:56 PM Alan C. Assis  wrote:
>
> > Hi Robert,
> > Thank you for the explanation! Is it about internal cache?
> >
> > Looking at
> >
> https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html
> > I can see that H723/5 shares mostly everything with H333/5.
> > I only tested NuttX on STM32H743ZI and STM32H753BI (I and Jorge added
> > support to this few weeks ago).
> >
> > Please take a look at Jorge's PRs, probably if you fix the memory in the
> > linker script and the clock tree for your board NuttX will work fine on
> it.
> >
> > BR,
> >
> > Alan
> >
> > On Wed, Jan 17, 2024 at 10:25 PM Robert Turner  wrote:
> >
> > > Apologies, I should have been more specific, I was referring to parts
> in
> > > the family which are not currently covered, such as the STM32H723xx
> which
> > > we use. The RAM sizes definitions in chip.h for
> > > CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for
> > > the  STM32H723xx and  STM32H725xx.
> > > BR,
> > > Robert
> > >
> > > On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis 
> wrote:
> > >
> > > > Robert,
> > > > STM32H7 family is already supported.
> > > >
> > > > Look at arch/arm/src/stm32h7 and equivalent at boards/
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Tuesday, January 16, 2024, Robert Turner 
> wrote:
> > > >
> > > > > Did anyone finish supporting the broader STM32H7xx family? If so,
> is
> > it
> > > > > close to being mergeable or sendable as a patch?
> > > > >
> > > > > Thanks,
> > > > > Robert
> > > > >
> > > > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl 
> > > wrote:
> > > > >
> > > > > > > You're right, but not entirely) For example, chips of different
> > > > > subseries
> > > > > > have different interrupt vector tables. Those. The
> > stm32h7x3xx_irq.h
> > > > file
> > > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or
> > > > > > RM0468. Although
> > > > > > some chips from all these series have 7x3 in the name.
> > > > > >
> > > > > > I think they are the same (not checked, intuition tells me so).
> But
> > > > some
> > > > > > peripherals are not available on some chips and then the
> > > > > > corresponding interrupt line is marked RESERVED, or its the same
> > > > > peripheral
> > > > > > but with upgraded functionality (QSPI/OCTOSPI) or
> > > > > > for some reason ST changed its name to confuse devs. There should
> > be
> > > no
> > > > > > conflict between IRQ lines.
> > > > > >
> > > > > > > Even if it duplicates 90% of the file it is better than
> #ifdefing
> > > the
> > > > > > > stm32h7x3xx_irq.h file. AKA ifdef rash!
> > > > > >
> > > > > > One file approach can be done with only one level of #ifdefs, one
> > > level
> > > > > of
> > > > > > #ifdefs doesn't have a ne

Re: Addition of STM32H7 MCU's

[Alan C. Assis]

Yes, this commit https://github.com/apache/nuttx/commit/8ceff0d

BR,

Alan

On Wed, Jan 17, 2024 at 11:31 PM Robert Turner  wrote:

> Nah not internal cache. The SRAM sizes for H723/5 are different from any of
> those defined in arch/arm/include/stm32h7/chip.h
> Suspect we need to get these correct as other files use these defs also,
> such as stm32_allocateheap.c
> Is Jorge's PR the one merged on Jul 12 (8ceff0d)?
> Thanks,
> Robert
>
> On Thu, Jan 18, 2024 at 2:56 PM Alan C. Assis  wrote:
>
> > Hi Robert,
> > Thank you for the explanation! Is it about internal cache?
> >
> > Looking at
> >
> https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html
> > I can see that H723/5 shares mostly everything with H333/5.
> > I only tested NuttX on STM32H743ZI and STM32H753BI (I and Jorge added
> > support to this few weeks ago).
> >
> > Please take a look at Jorge's PRs, probably if you fix the memory in the
> > linker script and the clock tree for your board NuttX will work fine on
> it.
> >
> > BR,
> >
> > Alan
> >
> > On Wed, Jan 17, 2024 at 10:25 PM Robert Turner  wrote:
> >
> > > Apologies, I should have been more specific, I was referring to parts
> in
> > > the family which are not currently covered, such as the STM32H723xx
> which
> > > we use. The RAM sizes definitions in chip.h for
> > > CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for
> > > the  STM32H723xx and  STM32H725xx.
> > > BR,
> > > Robert
> > >
> > > On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis 
> wrote:
> > >
> > > > Robert,
> > > > STM32H7 family is already supported.
> > > >
> > > > Look at arch/arm/src/stm32h7 and equivalent at boards/
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Tuesday, January 16, 2024, Robert Turner 
> wrote:
> > > >
> > > > > Did anyone finish supporting the broader STM32H7xx family? If so,
> is
> > it
> > > > > close to being mergeable or sendable as a patch?
> > > > >
> > > > > Thanks,
> > > > > Robert
> > > > >
> > > > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl 
> > > wrote:
> > > > >
> > > > > > > You're right, but not entirely) For example, chips of different
> > > > > subseries
> > > > > > have different interrupt vector tables. Those. The
> > stm32h7x3xx_irq.h
> > > > file
> > > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or
> > > > > > RM0468. Although
> > > > > > some chips from all these series have 7x3 in the name.
> > > > > >
> > > > > > I think they are the same (not checked, intuition tells me so).
> But
> > > > some
> > > > > > peripherals are not available on some chips and then the
> > > > > > corresponding interrupt line is marked RESERVED, or its the same
> > > > > peripheral
> > > > > > but with upgraded functionality (QSPI/OCTOSPI) or
> > > > > > for some reason ST changed its name to confuse devs. There should
> > be
> > > no
> > > > > > conflict between IRQ lines.
> > > > > >
> > > > > > > Even if it duplicates 90% of the file it is better than
> #ifdefing
> > > the
> > > > > > > stm32h7x3xx_irq.h file. AKA ifdef rash!
> > > > > >
> > > > > > One file approach can be done with only one level of #ifdefs, one
> > > level
> > > > > of
> > > > > > #ifdefs doesn't have a negative impact on code quality (but
> > > > > > it's probably a matter of individual feelings).
> > > > > > For IRQ and memory map (and probably DMAMUX), the approach with
> > > > separate
> > > > > > files may make sense but for peripheral definitions
> > > > > > I don't see any benefit in duplicating files.
> > > > > >
> > > > > > pt., 8 wrz 2023 o 12:01 
> > > > napisał(a):
> > > > > >
> > > > > > > You're right, but not entirely) For example, chips of different
> > > > > subseries
> > > > > > > have different interrupt vector tables. Those. The
> > > stm32h7x3xx_irq.h
> > > &

Re: Addition of STM32H7 MCU's

[Alan C. Assis]

Hi Robert,
Thank you for the explanation! Is it about internal cache?

Looking at
https://www.st.com/en/microcontrollers-microprocessors/stm32h7-series.html
I can see that H723/5 shares mostly everything with H333/5.
I only tested NuttX on STM32H743ZI and STM32H753BI (I and Jorge added
support to this few weeks ago).

Please take a look at Jorge's PRs, probably if you fix the memory in the
linker script and the clock tree for your board NuttX will work fine on it.

BR,

Alan

On Wed, Jan 17, 2024 at 10:25 PM Robert Turner  wrote:

> Apologies, I should have been more specific, I was referring to parts in
> the family which are not currently covered, such as the STM32H723xx which
> we use. The RAM sizes definitions in chip.h for
> CONFIG_STM32H7_STM32H7X3XX/CONFIG_STM32H7_STM32H7X5XX are incorrect for
> the  STM32H723xx and  STM32H725xx.
> BR,
> Robert
>
> On Thu, Jan 18, 2024 at 1:28 PM Alan C. Assis  wrote:
>
> > Robert,
> > STM32H7 family is already supported.
> >
> > Look at arch/arm/src/stm32h7 and equivalent at boards/
> >
> > BR,
> >
> > Alan
> >
> > On Tuesday, January 16, 2024, Robert Turner  wrote:
> >
> > > Did anyone finish supporting the broader STM32H7xx family? If so, is it
> > > close to being mergeable or sendable as a patch?
> > >
> > > Thanks,
> > > Robert
> > >
> > > On Fri, Sep 8, 2023 at 10:33 PM raiden00pl 
> wrote:
> > >
> > > > > You're right, but not entirely) For example, chips of different
> > > subseries
> > > > have different interrupt vector tables. Those. The stm32h7x3xx_irq.h
> > file
> > > > lists interrupt vectors for the RM0433, but not for the RM0455 or
> > > > RM0468. Although
> > > > some chips from all these series have 7x3 in the name.
> > > >
> > > > I think they are the same (not checked, intuition tells me so). But
> > some
> > > > peripherals are not available on some chips and then the
> > > > corresponding interrupt line is marked RESERVED, or its the same
> > > peripheral
> > > > but with upgraded functionality (QSPI/OCTOSPI) or
> > > > for some reason ST changed its name to confuse devs. There should be
> no
> > > > conflict between IRQ lines.
> > > >
> > > > > Even if it duplicates 90% of the file it is better than #ifdefing
> the
> > > > > stm32h7x3xx_irq.h file. AKA ifdef rash!
> > > >
> > > > One file approach can be done with only one level of #ifdefs, one
> level
> > > of
> > > > #ifdefs doesn't have a negative impact on code quality (but
> > > > it's probably a matter of individual feelings).
> > > > For IRQ and memory map (and probably DMAMUX), the approach with
> > separate
> > > > files may make sense but for peripheral definitions
> > > > I don't see any benefit in duplicating files.
> > > >
> > > > pt., 8 wrz 2023 o 12:01 
> > napisał(a):
> > > >
> > > > > You're right, but not entirely) For example, chips of different
> > > subseries
> > > > > have different interrupt vector tables. Those. The
> stm32h7x3xx_irq.h
> > > file
> > > > > lists interrupt vectors for the RM0433, but not for the RM0455 or
> > > > RM0468. Although
> > > > > some chips from all these series have 7x3 in the name.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > *От:* "raiden00pl" 
> > > > > *Кому:* "undefined" 
> > > > > *Отправлено:* пятница, 8 сентября 2023 г., 12:52
> > > > > *Тема:* Re: Addition of STM32H7 MCU's
> > > > >
> > > > > From what I'm familiar with STM32H7, all chips use the same
> registers
> > > and
> > > > > bit definitions.
> > > > > Therefore, keeping definitions for different chips in different
> files
> > > > > doesn't make sense in my opinion.
> > > > > The only problem is that some chips support some peripherals while
> > > others
> > > > > do not. But this can be
> > > > > solved using definitions from Kconfig, where we define the
> supported
> > > > > peripherals anyway, using
> > > > > `select STM32H7_HAVE_xxx`. In that case, it's possible to have only
> > one
> > > > > version of files with hardware
> > > > > definitions (ir