./tools/configure.sh | find -L | to follow symlinks

[Simon Filgis]

Dear all,

I have my own board assembled with Atmel SAME70 and I would like to work on
the board files "outside" the nuttix structure in a separate folder
(custom_board). Now I symlinked my custom_board folder into nuttx:

cd ../nuttx/boards/arm/samv7
> ln -s ../../../../custom_board/ custom_board


This only works if the find command gets a -L (follow symlinks) in

function dumpcfgs
> {
>   configlist=`find -L ${TOPDIR}/boards -name defconfig`
>   for defconfig in ${configlist}; do
> config=`dirname ${defconfig} | sed -e "s,${TOPDIR}/boards/,,g"`
> boardname=`echo ${config} | cut -d'/' -f3`
> configname=`echo ${config} | cut -d'/' -f5`
> echo "  ${boardname}:${configname}"
>   done
> }


Has anybody any concern in adding -L to the find or in general with my
approach?

Regards,

Simon

Ingenieurbüro-Filgis
USt-IdNr.: DE305343278

Re: ./tools/configure.sh | find -L | to follow symlinks

[Simon Filgis]

Better!
Thank you!

On Tue, Aug 3, 2021 at 10:20 AM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> > Regarding my advice from a few minutes ago. Somebody in
> >
> https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721138548
> > complains that
> > the process is not working.
>
>
> That's only when the board is part of a group that has the "common"
> directory and the common directory isn't wanted.  So more tweaking was
> needed there.
> The SAMxx families don't have that, so creating a custom board from
> the in-tree boards is straightforward.
>
>
> On Tue, Aug 3, 2021 at 10:16 AM Maciej Wójcik  wrote:
> >
> > Regarding my advice from a few minutes ago. Somebody in
> >
> https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721138548
> > complains that
> > the process is not working.
> >
> > Just to be sure I will test it today and maybe finish that documentation.
> > If I won't, still just try what is described there. I am sorry for the
> > inconvenience. It looks a bit complicated, but it is quite simple in the
> > end.
> >
> > Am Di., 3. Aug. 2021 um 10:10 Uhr schrieb Maciej Wójcik <
> w8j...@gmail.com>:
> >
> > > In general, you probably don't want to change files in the OS
> repository
> > > just to attach your board.
> > >
> > > I was supposed to document how to do this correctly, more than a half
> year
> > > ago. I didn't, but what you need is described in this issue
> > >
> https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721138548
> > >
> > > The whole idea is to call `./config.sh` with a relative path. Other
> than
> > > this you need to nest your board configuration in particular folder
> > > structure. I don't remember exactly, but what is in that issue is
> correct
> > > and supported.
> > >
> > > Am Di., 3. Aug. 2021 um 09:57 Uhr schrieb Simon Filgis <
> > > si...@ingenieurbuero-filgis.de>:
> > >
> > >> Dear all,
> > >>
> > >> I have my own board assembled with Atmel SAME70 and I would like to
> work
> > >> on
> > >> the board files "outside" the nuttix structure in a separate folder
> > >> (custom_board). Now I symlinked my custom_board folder into nuttx:
> > >>
> > >> cd ../nuttx/boards/arm/samv7
> > >> > ln -s ../../../../custom_board/ custom_board
> > >>
> > >>
> > >> This only works if the find command gets a -L (follow symlinks) in
> > >>
> > >> function dumpcfgs
> > >> > {
> > >> >   configlist=`find -L ${TOPDIR}/boards -name defconfig`
> > >> >   for defconfig in ${configlist}; do
> > >> > config=`dirname ${defconfig} | sed -e "s,${TOPDIR}/boards/,,g"`
> > >> > boardname=`echo ${config} | cut -d'/' -f3`
> > >> > configname=`echo ${config} | cut -d'/' -f5`
> > >> > echo "  ${boardname}:${configname}"
> > >> >   done
> > >> > }
> > >>
> > >>
> > >> Has anybody any concern in adding -L to the find or in general with my
> > >> approach?
> > >>
> > >> Regards,
> > >>
> > >> Simon
> > >>
> > >> Ingenieurbüro-Filgis
> > >> USt-IdNr.: DE305343278
> > >>
> > >
>

Same70 adc

[Simon Filgis]

Dear all,

has anybody implemented adc for same70? That would be nice!

Regards,

Simon

Re: Same70 adc

[Simon Filgis]

Hi Alan,

that is what I started today. It turns out to be a good exercise.

Nuttx is fun :)

Regards,

Simon

--

Alan Carvalho de Assis  schrieb am Di., 3. Aug. 2021,
17:27:

> Hi Simon,
>
> I didn't look the SAME70 datasheet/reference manual, but probably the
> ADC is similar to SAMA5, normally the manufacturer reuse their IP
> around many chips families.
>
> Please use the arch/arm/src/sama5/sam_adc.c as reference to implement
> the same70 ADC driver.
>
> BR,
>
> Alan
>
> On 8/3/21, Simon Filgis  wrote:
> > Dear all,
> >
> > has anybody implemented adc for same70? That would be nice!
> >
> > Regards,
> >
> > Simon
> >
>

Re: Same70 adc, CAN and NuttX in general

[Simon Filgis]

7622
>  182 00 Praha 8  WWW:   http://www.pikron.com/
>  Czech Republic  e-mail:  pik...@pikron.com
> ==
>
>
> On Tuesday 03 of August 2021 21:20:28 Alan Carvalho de Assis wrote:
> > > Alan Carvalho de Assis  schrieb am Di., 3. Aug.
> 2021,
> > >
> > > 17:27:
> > >> Hi Simon,
> > >>
> > >> I didn't look the SAME70 datasheet/reference manual, but probably the
> > >> ADC is similar to SAMA5, normally the manufacturer reuse their IP
> > >> around many chips families.
> > >>
> > >> Please use the arch/arm/src/sama5/sam_adc.c as reference to implement
> > >> the same70 ADC driver.
> > >>
> > >> BR,
> > >>
> > >> Alan
> > >>
> > >> On 8/3/21, Simon Filgis  wrote:
> > >> > Dear all,
> > >> >
> > >> > has anybody implemented adc for same70? That would be nice!
> > >> >
> > >> > Regards,
> > >> >
> > >> > Simon
>
>
>

Re: Nuttx RTOS with Nucleo-H743ZI2 board

[Simon Filgis]

Hi Sir,

split you problem:

Have you verified that you're able to receive data with your PC from any
known working embedded device.

Best,

Simon


On Tue, Aug 10, 2021 at 12:11 PM rushi ghatkar 
wrote:

> Hi Sir,
>
> Thanks. Appreciate for your help.
>
> I have flashed your firmware file, nuttx.bin , but still I'm not getting
> nsh> prompt.
>
> Its ok sir. Thanks for your help.
>
>
>
> Thanks & Regards,
> Rushikesh Ghatkar
>
> On Tue, Aug 10, 2021 at 3:29 PM Murat Tologlu 
> wrote:
>
> > Hi,
> >
> > Your nuttx.bin is probably different than the nuttx.bin file which I sent
> > to you that's why I configured and compiled an sent to you a new one for
> > your sake; If you still can't get  the nsh> prompt with the firmware I
> sent
> > to you I don't have any more answer for you. Maybe someone else can
> > contribute.
> >
> > Good luck.
> >
> > From: rushi ghatkar 
> > Sent: Tuesday, August 10, 2021 12:24 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: Nuttx RTOS with Nucleo-H743ZI2 board
> >
> >
> >
> > On Tue, Aug 10, 2021 at 2:52 PM rushi ghatkar  > > wrote:
> > Hi Sir,
> >
> > Thanks for your reply. Really appreciate it.
> >
> > When i configured and compiled nuttx rtos then in my system nuttx.bin
> file
> > was created. And I have flashed that file also. Please find the nuttx
> > directory image attachment.
> >
> > Your firmware file, nuttx bin file I have flashed successfully using
> > STM32CubeProgramer.
> >
> > But the issue is,
> > 1. picocom or minicom is not working.
> > 2. I want to create my own driver like PWM, ADC and for other
> peripherals,
> > for this where I should start to create? and how?
> >
> >
> > Thanks & Regards,
> > Rushikesh Ghatkar
> >
> >
> >
> >
> > On Tue, Aug 10, 2021 at 2:33 PM Murat Tologlu  > > wrote:
> > Hi Rushikesh,
> >
> > Flash and try attached firmware ( you may try bin and hex files ) and
> tell
> > us what happens.
> >
> > Good luck,
> > Murat
> >
> > From: rushi ghatkar  > rushighatka...@gmail.com>>
> > Sent: Tuesday, August 10, 2021 9:42 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: Nuttx RTOS with Nucleo-H743ZI2 board
> >
> > Hi,
> >
> > Thanks for your reply.
> >
> > I have followed this youtube video from Nuttx Channel,
> >
> >
> https://www.youtube.com/watch?v=heSkSd-_70g&list=PLd73yQk5Fd8JEsVD-lhwYRQKVu6glfDa8&index=1
> >
> > From the above link I have followed each step exactly as it is.
> >
> > I'm using Nucleo-H743ZI2 board which has stlink-v3, for this in the end I
> > was trying to execute command "openocd -f interface/stlink-v3.cfg -f
> > target/stm32h7x.cfg" but this gives error. Please find the error image
> > attachment.
> > As you asked, use STM32CubeProgrammer to flash nuttx.bin into the
> > Nucleo-H743ZI2 board. And I used it and the nuttx.bin file has been
> flashed
> > successfully.
> >
> > After all this I was trying to open the nutshell using picocom, but
> > nothing happened. No nutshell prompt appeared.
> >
> > Please help me to solve this issue.
> >
> >
> > Thanks & Regards,
> > Rushikesh Ghatkar
> >
> >
> > On Tue, Aug 10, 2021 at 11:39 AM murat tologlu  > > wrote:
> > Hi Rushikesh,
> >
> > If you copy paste and share in a file attachment all the command line
> > content from "$ cd nuttxspace/nuttx" to the end - not only picocom
> output "
> > but everything that you did to configure and compile fooling "a video" (
> > which video? ) , perhaps we help can you.
> >
> > Regards,
> > Murat
> >
> > On 2021/08/10 05:00:36, rushi ghatkar  > rushighatka...@gmail.com>> wrote:
> > > Hi,
> > >
> > > I have followed a youtube video from Nuttx Channel to configure and
> > compile
> > > Nuttx rtos with Nucleo-H743ZI2. And with the help of
> STM32CUbeProgrammer
> > I
> > > have also flashed the nuttx.bin file into the board.
> > > But when I was trying to use minicom or picocom, I'm unable to use it.
> > > After executing this command "*sudo picocom /dev/ttyACM0 -b 115200" *,
> > > nutshell prompt is not appearing, please find the attachment.
> > > Need help for this.
> > >
> > >
> > > Regards,
> > > Rushikesh Ghatkar
> > >
> > > On Mon, Aug 9, 2021 at 8:17 PM murat tologlu  > > wrote:
> > >
> > > > Hi Rushi,
> > > >
> > > > Unless we know what you are trying to do we can't help you. There may
> > be a
> > > > mistake anywhere!
> > > >
> > > > Explain what did you try so far, how ? Give us the links of the
> > > > application you're trying.. So may be we can discover your mistake.
> > > >
> > > > Regards,
> > > > Murat
> > > >
> > > > On 2021/08/09 04:36:22, rushi ghatkar  > > wrote:
> > > > > Hi,
> > > > >
> > > > > I'm totally new to NUttx RTOS and I have started to work on it. I
> > have a
> > > > > Nucleo-H743ZI2 board and followed a youtube video of Nuttx channel
> to
> > > > > configure, compile and flash Nuttx rtos in Nucleo-H743ZI2 board.
> > After
> > > > > co

not reached any more ?!

[Simon Filgis]

Dear all,

since yesterday's upstream fetch, my custom board is not working any more.

Basically it is a copy of same70_explained:nsh ...

ADC, CAN, ETHERNET is not any more in /dev/
nsh is prompting fine...

board_app_initialize() is not called any more.

I think it has something to do with the following commit: Rename
CONFIG_LIB_BOARDCTL to CONFIG_BOARDCTL.

Does somebody have a hint where to search?

Simon

Re: not reached any more ?!

[Simon Filgis]

Hi Nathan,

You mean this option?
[image: image.png]

Makes no difference.

I checked all the points in the list of cwiki. I did not miss a single line.

I have attached my board's Kconfig and defconfig file, could you please
have a look?

Simon



On Wed, Aug 11, 2021 at 3:03 PM Nathan Hartman 
wrote:

> On Wed, Aug 11, 2021 at 8:32 AM Nathan Hartman 
> wrote:
>
> > On Wed, Aug 11, 2021 at 8:28 AM Simon Filgis <
> > si...@ingenieurbuero-filgis.de> wrote:
> >
> >> Dear all,
> >>
> >> since yesterday's upstream fetch, my custom board is not working any
> more.
> >>
> >> Basically it is a copy of same70_explained:nsh ...
> >>
> >> ADC, CAN, ETHERNET is not any more in /dev/
> >> nsh is prompting fine...
> >>
> >> board_app_initialize() is not called any more.
> >>
> >> I think it has something to do with the following commit: Rename
> >> CONFIG_LIB_BOARDCTL to CONFIG_BOARDCTL.
> >>
> >> Does somebody have a hint where to search?
> >>
> >> Simon
> >
> >
> >
> > Yes. That Kconfig was renamed so your board's Kconfig needs to be updated
> > to the new name.
> >
> > You can run make menuconfig and enable BOARDCTL, then run make
> > savedefconfig and copy the defconfig file from nuttx/ to your board's
> > config directiry.
> >
> > It's documented in the release notes on CWIKI, let me find the link...
> >
> >
> Since this hasn't been released yet it's in the work in progress release
> notes:
>
> Under "changes to Kconfig":
> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+10.2
>
> (If you're on mobile you may need to request the desktop version.)
>
> Cheers,
> Nathan
>

Re: not reached any more ?!

[Simon Filgis]

That is done:
[image: image.png]

Any other ideas?

By the way: is it OK to double include sam_bringup.c in line 30 and 35?


I will go back to an older state for verification of the assumptions.


Simon

On Wed, Aug 11, 2021 at 3:59 PM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> Please check your board/_path_/src/Makefile and check that your
> CONFIG_ are all in the new format, i.e.: CONFIG_LIB_BOARDCTL to
> CONFIG_BOARDCTL
>
>
> On Wed, Aug 11, 2021 at 3:56 PM Simon Filgis
>  wrote:
> >
> > Hi Nathan,
> >
> > You mean this option?
> >
> >
> > Makes no difference.
> >
> > I checked all the points in the list of cwiki. I did not miss a single
> line.
> >
> > I have attached my board's Kconfig and defconfig file, could you please
> have a look?
> >
> > Simon
> >
> >
> >
> > On Wed, Aug 11, 2021 at 3:03 PM Nathan Hartman 
> wrote:
> >>
> >> On Wed, Aug 11, 2021 at 8:32 AM Nathan Hartman <
> hartman.nat...@gmail.com>
> >> wrote:
> >>
> >> > On Wed, Aug 11, 2021 at 8:28 AM Simon Filgis <
> >> > si...@ingenieurbuero-filgis.de> wrote:
> >> >
> >> >> Dear all,
> >> >>
> >> >> since yesterday's upstream fetch, my custom board is not working any
> more.
> >> >>
> >> >> Basically it is a copy of same70_explained:nsh ...
> >> >>
> >> >> ADC, CAN, ETHERNET is not any more in /dev/
> >> >> nsh is prompting fine...
> >> >>
> >> >> board_app_initialize() is not called any more.
> >> >>
> >> >> I think it has something to do with the following commit: Rename
> >> >> CONFIG_LIB_BOARDCTL to CONFIG_BOARDCTL.
> >> >>
> >> >> Does somebody have a hint where to search?
> >> >>
> >> >> Simon
> >> >
> >> >
> >> >
> >> > Yes. That Kconfig was renamed so your board's Kconfig needs to be
> updated
> >> > to the new name.
> >> >
> >> > You can run make menuconfig and enable BOARDCTL, then run make
> >> > savedefconfig and copy the defconfig file from nuttx/ to your board's
> >> > config directiry.
> >> >
> >> > It's documented in the release notes on CWIKI, let me find the link...
> >> >
> >> >
> >> Since this hasn't been released yet it's in the work in progress release
> >> notes:
> >>
> >> Under "changes to Kconfig":
> >> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+10.2
> >>
> >> (If you're on mobile you may need to request the desktop version.)
> >>
> >> Cheers,
> >> Nathan
>

Re: not reached any more ?!

[Simon Filgis]

Dear all,

OK.

nuttx -> master
apps -> something old

after pulling apps the problem is solved. I realized this when looking at
several new warnings, that are also gone now.

Thanks for the awesome support :)

Simon


On Wed, Aug 11, 2021 at 4:51 PM Alan Carvalho de Assis 
wrote:

> Hi Simon,
>
> It is not included twice, see now with indentation:
>
> ifeq ($(CONFIG_BOARDCTL),y)
>   CSRCS += sam_appinit.c sam_bringup.c
>
>   ifeq ($(CONFIG_BOARDCTL_RESET),y)
> CSRCS += sam_reset.c
>   endif
> else ifeq ($(CONFIG_BOARD_LATE_INITIALIZE),y)
>   CSRCS += sam_bringup.c
> endif
>
> BR,
>
> Alan
>
> On 8/11/21, Simon Filgis  wrote:
> > That is done:
> > [image: image.png]
> >
> > Any other ideas?
> >
> > By the way: is it OK to double include sam_bringup.c in line 30 and 35?
> >
> >
> > I will go back to an older state for verification of the assumptions.
> >
> >
> > Simon
> >
> > On Wed, Aug 11, 2021 at 3:59 PM Abdelatif Guettouche <
> > abdelatif.guettou...@gmail.com> wrote:
> >
> >> Please check your board/_path_/src/Makefile and check that your
> >> CONFIG_ are all in the new format, i.e.: CONFIG_LIB_BOARDCTL to
> >> CONFIG_BOARDCTL
> >>
> >>
> >> On Wed, Aug 11, 2021 at 3:56 PM Simon Filgis
> >>  wrote:
> >> >
> >> > Hi Nathan,
> >> >
> >> > You mean this option?
> >> >
> >> >
> >> > Makes no difference.
> >> >
> >> > I checked all the points in the list of cwiki. I did not miss a single
> >> line.
> >> >
> >> > I have attached my board's Kconfig and defconfig file, could you
> please
> >> have a look?
> >> >
> >> > Simon
> >> >
> >> >
> >> >
> >> > On Wed, Aug 11, 2021 at 3:03 PM Nathan Hartman
> >> > 
> >> wrote:
> >> >>
> >> >> On Wed, Aug 11, 2021 at 8:32 AM Nathan Hartman <
> >> hartman.nat...@gmail.com>
> >> >> wrote:
> >> >>
> >> >> > On Wed, Aug 11, 2021 at 8:28 AM Simon Filgis <
> >> >> > si...@ingenieurbuero-filgis.de> wrote:
> >> >> >
> >> >> >> Dear all,
> >> >> >>
> >> >> >> since yesterday's upstream fetch, my custom board is not working
> >> >> >> any
> >> more.
> >> >> >>
> >> >> >> Basically it is a copy of same70_explained:nsh ...
> >> >> >>
> >> >> >> ADC, CAN, ETHERNET is not any more in /dev/
> >> >> >> nsh is prompting fine...
> >> >> >>
> >> >> >> board_app_initialize() is not called any more.
> >> >> >>
> >> >> >> I think it has something to do with the following commit: Rename
> >> >> >> CONFIG_LIB_BOARDCTL to CONFIG_BOARDCTL.
> >> >> >>
> >> >> >> Does somebody have a hint where to search?
> >> >> >>
> >> >> >> Simon
> >> >> >
> >> >> >
> >> >> >
> >> >> > Yes. That Kconfig was renamed so your board's Kconfig needs to be
> >> updated
> >> >> > to the new name.
> >> >> >
> >> >> > You can run make menuconfig and enable BOARDCTL, then run make
> >> >> > savedefconfig and copy the defconfig file from nuttx/ to your
> >> >> > board's
> >> >> > config directiry.
> >> >> >
> >> >> > It's documented in the release notes on CWIKI, let me find the
> >> >> > link...
> >> >> >
> >> >> >
> >> >> Since this hasn't been released yet it's in the work in progress
> >> >> release
> >> >> notes:
> >> >>
> >> >> Under "changes to Kconfig":
> >> >> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+10.2
> >> >>
> >> >> (If you're on mobile you may need to request the desktop version.)
> >> >>
> >> >> Cheers,
> >> >> Nathan
> >>
> >
>

Lin

[Simon Filgis]

Dear all,

has anybody implemented a LIN driver for SAME70 USART? The SAME70 USART
peripheral is capable of. A SW implementation (sllin.c - Pavel Pisa) would
also be interesting!

Would you extend sma_lowputc.c and sam_serial.c or would you grep USARTx in
a separate file?

Have a good Weekend,

Simon

Re: Poll: Which OS are you using to compile NuttX?

[Simon Filgis]

:'D



Russell Haley  schrieb am Fr., 24. Sept. 2021, 21:57:

> The link gives me “This post cannot be displayed”. I am logged into the
> Microsoft data collection site known as LinkedIn.
>
> Sent from Mail for Windows
>
> From: Tim Hardisty
> Sent: Friday, September 24, 2021 12:54 PM
> To: dev@nuttx.apache.org
> Subject: Re: Poll: Which OS are you using to compile NuttX?
>
> Needs a LinkedIn login?
>
>
>
> From: Alan Carvalho de Assis 
> Reply to: "dev@nuttx.apache.org" 
> Date: Friday, 24 September 2021 at 20:20
> To: dev 
> Subject: Poll: Which OS are you using to compile NuttX?
>
> Hi Everyone, Please help us to discover which OS people are using most to
> compile NuttX:
> https://www.linkedin.com/feed/update/urn:li:activity:6847246067046596609/
> It will help us to decide how better support your host OS. BR, Alan
>
>

Re: Which control version software are you using? //was Re: Poll: Which OS are you using to compile NuttX?

[Simon Filgis]

What does your script do?

David S. Alessio  schrieb am Sa., 25. Sept.
2021, 01:02:

> I’d like to see my git version script be brought back into mainstream.
>
> > On Sep 24, 2021, at 3:58 PM, Alan Carvalho de Assis 
> wrote:
> >
> > Hi David,
> >
> > Nice you hear from you.
> >
> > I'm also using git: #1
> >
> > BR,
> >
> > Alan
> >
> > On 9/24/21, David S. Alessio  wrote:
> >> Hi, Alan,
> >>
> >> It’d be good to know how developers are managing their code:
> >> 1) git
> >> 2) mercurial
> >> 3) SVN
> >> 4) zip files on floppies
> >> 5) none
> >>
> >> My money is on #1 ;)
> >>
> >> Cheers,
> >> -david
> >>
> >>> On Sep 24, 2021, at 2:07 PM, Alan Carvalho de Assis  >
> >>> wrote:
> >>>
> >>> Hi Flávio,
> >>>
> >>> That is good idea, but I think we need to have some kind of
> maintainers.
> >>>
> >>> It is hard when someone adds some strange OS and the go out and leave
> >>> it to other developers to maintain it.
> >>>
> >>> Do you want to mainline some host OS? :-P
> >>>
> >>> BR,
> >>>
> >>> Alan
> >>>
> >>> On 9/24/21, Flavio Castro Alves Filho  wrote:
>  Alan,
> 
>  How about a poll asking "which other OS would you like to build
> NuttX?"
>  :-P
> 
>  Best regards,
> 
>  Flavio
> 
>  Em sex., 24 de set. de 2021 às 17:45, Tim Hardisty
>   escreveu:
> >
> > Linux
> >
> >
> >
> > On 24/09/2021, 21:07, "Alan Carvalho de Assis" 
> > wrote:
> >
> >   Sorry guys, I suppose you are using LinkedIn too.
> >
> >   Yes, probably it will collect some data from you, but you are using
> > a
> >   better MS gather:
> >
> >   "Sent from Mail for Windows"
> >
> >   So, if you are already in the hell, please give a warm hug in the
> > Lucifer :-D
> >
> >   Now, let be serious here: for those who don't have LinkedIn access,
> >   please reply this email with one of these options:
> >
> >   1) Linux
> >   2) MacOS
> >   3) Windows using Cygwin
> >   4) Windows Native
> >
> >   Thank you for the understanding.
> >
> >   BR,
> >
> >   Alan
> >
> >   On 9/24/21, Russell Haley  wrote:
> >> The link gives me “This post cannot be displayed”. I am logged into
> > the
> >> Microsoft data collection site known as LinkedIn.
> >>
> >> Sent from Mail for Windows
> >>
> >> From: Tim Hardisty
> >> Sent: Friday, September 24, 2021 12:54 PM
> >> To: dev@nuttx.apache.org
> >> Subject: Re: Poll: Which OS are you using to compile NuttX?
> >>
> >> Needs a LinkedIn login?
> >>
> >>
> >>
> >> From: Alan Carvalho de Assis 
> >> Reply to: "dev@nuttx.apache.org" 
> >> Date: Friday, 24 September 2021 at 20:20
> >> To: dev 
> >> Subject: Poll: Which OS are you using to compile NuttX?
> >>
> >> Hi Everyone, Please help us to discover which OS people are using
> > most to
> >> compile NuttX:
> >>
> >
> https://www.linkedin.com/feed/update/urn:li:activity:6847246067046596609/
> > It
> >> will help us to decide how better support your host OS. BR, Alan
> >>
> >>
> >
> >
> 
> 
>  --
>  Flavio de Castro Alves Filho
> 
>  flavio.al...@gmail.com
>  Twitter: http://twitter.com/#!/fraviofii
>  LinkedIn profile: www.linkedin.com/in/flaviocastroalves
> 
> >>
> >>
>
>

Re: Which control version software are you using? //was Re: Poll: Which OS are you using to compile NuttX?

[Simon Filgis]

Dear all,

@David, thank you for your explanation.

I started research on the implementation of uname. From there I came across
the nuttx/version.sh

Within I find:

> # Get GIT information (if not provided on the command line)
> if [ -z "${BUILD}" ]; then
>   BUILD=`git -C ${WD} log --oneline -1 | cut -d' ' -f1 2>/dev/null`
>   if [ -z "${BUILD}" ]; then
> echo "GIT version information is not available"
> exit 5
>   fi
>   if [ -n "`git -C ${WD} diff-index --name-only HEAD | head -1`" ]; then
> BUILD=${BUILD}-dirty
>   fi
> fi


Am I right with my assumption that it is possible to feed additional custom
GIT / SVN / 'What else' information into the build via command line? That
would suffice the needed flexibility, wouldn't it?


Regards,


Simon



On Sun, Sep 26, 2021 at 8:45 PM Gregory Nutt  wrote:

>
> > I wonder what is the purpose of this question.
> The problem with these polls is that everyone sees right through them..
> at least at some level.  They are all really the question , "Who can we
> f*ck over."
>

controll sleep pin of uart tranceiver via ioctl

[Simon Filgis]

Dear all,

I have two LIN transceivers on my board with a dedicated sleep pin. I want
to use the sleep functionality in my app.

I tried the following:
1. have sam_serial.c be aware of a *board_init() and a *board_disable(bool
disable) for every uartX
2. call *bard_init() in setup
3. make *board_disable(bool disable) available via ioctl
4. have board implementation of  *bard_init() and *board_disable(bool
disable) for every used uartX

https://github.com/SimonFilgis/incubator-nuttx/commit/0cdc16192970b14397a02e886c9187a55ca77604

What do you think? Does anybody have a better idea, or is there maybe
already a solution?

Regards,

Simon

** untested in HW as I'm in home office - will be tested tomorrow

Re: controll sleep pin of uart tranceiver via ioctl

[Simon Filgis]

Thanks for the hint ;)

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Wed, Oct 6, 2021 at 7:32 PM Alan Carvalho de Assis 
wrote:

> Hi Simon,
>
> I think the sleep pin should be used in a more generic way, for instance,
> you can use the NuttX Power Management subsystem to control the CAN sleep
> pin.
>
> BR,
>
> Alan
>
> On Wednesday, October 6, 2021, Simon Filgis <
> si...@ingenieurbuero-filgis.de>
> wrote:
>
> > Dear all,
> >
> > I have two LIN transceivers on my board with a dedicated sleep pin. I
> want
> > to use the sleep functionality in my app.
> >
> > I tried the following:
> > 1. have sam_serial.c be aware of a *board_init() and a
> *board_disable(bool
> > disable) for every uartX
> > 2. call *bard_init() in setup
> > 3. make *board_disable(bool disable) available via ioctl
> > 4. have board implementation of  *bard_init() and *board_disable(bool
> > disable) for every used uartX
> >
> > https://github.com/SimonFilgis/incubator-nuttx/commit/
> > 0cdc16192970b14397a02e886c9187a55ca77604
> >
> > What do you think? Does anybody have a better idea, or is there maybe
> > already a solution?
> >
> > Regards,
> >
> > Simon
> >
> > ** untested in HW as I'm in home office - will be tested tomorrow
> >
>

Re: NuttX + MicroPython + ESP32 / ESP32-C3

[Simon Filgis]

Hi,

this is a good example why discussion on discord channel is tricky. The
discussion was good. Learned a lot. I managed to build PR840, simple math
on the micropython console was possible.

However I stopped the work because:
1. I got distracted in running daily business
2. I need to admit my skills*freetime=projectpower is not sufficient for
attacking

...but I have the mission micropython in the back of my head.

Looking forward to more discussion wherever (discord or mail, I don't
care), but please keep me in the loop ;)

Thank you,

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Mon, Oct 25, 2021 at 4:58 PM Xiang Xiao 
wrote:

> McKay made a new porting here:
> Pull requests · apache/incubator-nuttx-apps (github.com)
> 
> Maybe, you could work with him to boost the porting.
>
> On Mon, Oct 25, 2021 at 10:44 PM Alan Carvalho de Assis  >
> wrote:
>
> > Hi Tomasz,
> >
> > MicroPython was integrated in NuttX at some time ago, but it started
> > to crash and was removed.
> >
> > I think someone started a discussion about it on discord, but I don't
> > know what happened later.
> >
> > As I told you ESP32-C3 has a good support on NuttX and Xiaomi is
> > already using it internally (it passed on their certification
> > process).
> >
> > BR,
> >
> > Alan
> >
> > On 10/25/21, Tomasz CEDRO  wrote:
> > > Hello world :-)
> > >
> > > I am considering MicroPython as the rapid development platform. It
> > > seems well developed already, allows simple tasks extremely fast, also
> > > allows client to develop firmware on their own relatively easy without
> > > rebuilding whole firmware, getting into details, drivers, etc.
> > >
> > > I would like to ask what is the current state of MicroPython in NuttX
> > RTOS?
> > >
> > > What would be the proper way to autostart application and/or
> > > MicroPython + main.py script on boot?
> > >
> > > Are all CPU/SoC supported over HAL or I will have to write
> > > implementation on my own?
> > >
> > > Is ESP32-C3 fully supported? Is ESP32-PICO fully supported as ESP32
> > > derivative?
> > >
> > > I have also some M5Stack devices with LCD (M5StickC) even with Camera
> > > (M5StickV). They can use LVGL and I can see LVGL and LCD drivers are
> > > already ported to NuttX :-) M5StickV even has 64-bit RISC-V RV64IMAFDC
> > > (RV64GC) with NeuralNetwork accelerator! All of them cost way below
> > > $50 :-)
> > >
> > > MicroPython seems really amazing way to quickly create
> > > Proof-of-Concept designs :-)
> > >
> > > Any hints welcome :-)
> > > Tomek
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
> >
>

SPI with DMA on SAME70

[Simon Filgis]

Dear all,

I'm using ST7789.c in combination with lvgl-lib.

The bottleneck to the display is the SPI communication. But even if I
increase the SPI frequency to 24MHz, it does not get faster. This is
because of constant delay between the bytes.

I guessed that this can be improved using DMA. But that does not seem to
work out of the box. In the SPI TX callback the result of the DMA transfer
is -4. The transfer is not executed.

Can anybody give me a hint on what to do?

Best regards,

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278

Re: SPI with DMA on SAME70

[Simon Filgis]

Hello Michael,

Thank you for your answer. That is true, SPI driver's initial flag setup is
0.

The flags are evaluated dynamically and very meaningful
within spi_exchange() and set via

  sam_dmaconfig(spics->rxdma, rxflags);
  sam_dmaconfig(spics->txdma, txflags);

I will try with setup initial flags to try.

Any hint to debug is appreciated :)


Simon


--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Tue, Feb 8, 2022 at 12:17 PM Michal Lenc  wrote:

> Hello Simon,
>
>
>
> I did take a look into SPI driver for SAME70 a few months ago. The one
> thing
> that was a little bit weird to me was the lack of DMA flags passed to sam_
> dmachannel() function (somewhere here https://github.com/apache/incubator-
> nuttx/blob/master/arch/arm/src/samv7/sam_spi.c#L2043
> <https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam_spi.c#L2043>)
> compared to the flags
> I needed to select for ADC DMA support to function correctly (https://
>
> github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam_afec.c#
> L1125
> <http://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam_afec.c#L1125>).
> I didn't invest more time into it as we had other priorities back
> then and I think we sticked with SPI without DMA. But it could be one of
> the
> problems.
>
>
>
>
> You can also take a look into sam_afec.c file, the DMA is working fine
> there. Hope this helps.
>
> Best regards,
> Michal Lenc
>
> -- Původní e-mail --
> Od: Simon Filgis 
> Komu: dev@nuttx.apache.org
> Datum: 8. 2. 2022 11:52:38
> Předmět: SPI with DMA on SAME70
> "Dear all,
>
> I'm using ST7789.c in combination with lvgl-lib.
>
> The bottleneck to the display is the SPI communication. But even if I
> increase the SPI frequency to 24MHz, it does not get faster. This is
> because of constant delay between the bytes.
>
> I guessed that this can be improved using DMA. But that does not seem to
> work out of the box. In the SPI TX callback the result of the DMA transfer
> is -4. The transfer is not executed.
>
> Can anybody give me a hint on what to do?
>
> Best regards,
>
> Simon
>
> --
> Hard- and Softwaredevelopment Consultant
> Ingenieurbüro-Filgis
> USt-IdNr.: DE305343278
> "

Re: SPI with DMA on SAME70

[Simon Filgis]

Dear all,

I started to follow up this topic.

Found that one in sam_hsmci.c:

/* There is some unresolved issue with the SAMV7 DMA.  TX DMA is currently
 * disabled.
 */


#undef  HSCMI_NORXDMA  /* Define to disable RX DMA */
*#define HSCMI_NOTXDMA1 /* Define to disable TX DMA */*


That fits my (and Michael Lenc's) experience that DMA peripheral to memory
works. Memory to the peripheral seems broken though.

I will therefore debug *sam_xdmax.c*. Even if I find some odd comments on
DMA timeouts in sam_spi.c.

If anybody has a better idea, or remembers details ;), please give feedback.

BR,

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Tue, Feb 8, 2022 at 11:52 AM Simon Filgis 
wrote:

> Dear all,
>
> I'm using ST7789.c in combination with lvgl-lib.
>
> The bottleneck to the display is the SPI communication. But even if I
> increase the SPI frequency to 24MHz, it does not get faster. This is
> because of constant delay between the bytes.
>
> I guessed that this can be improved using DMA. But that does not seem to
> work out of the box. In the SPI TX callback the result of the DMA transfer
> is -4. The transfer is not executed.
>
> Can anybody give me a hint on what to do?
>
> Best regards,
>
> Simon
>
> --
> Hard- and Softwaredevelopment Consultant
> Ingenieurbüro-Filgis
> USt-IdNr.: DE305343278
>

Re: SPI with DMA on SAME70

[Simon Filgis]

Hi Michael,

I'm doing the work to offload CPU from display activity. It would be very
nice if SD-Card and UART could also profit on samv7 :)

I tested DMA with SPI and it works (althought I can write only to one half
> of the display but that might be some my problems in configuration if all
> your tests were fine)


I have the same experience with the display. Only half is written. But the
blocksize seems to be complete. Therefore I assume that half of the line is
correct data. The other half of the line is wrong data. How many pixels
does your display line have? Mine has 240.

Regards,

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Sun, Feb 20, 2022 at 10:17 PM Michal Lenc  wrote:

> Hello Simon,
>
>
>
> I had noticed your DMA fix PR (https://github.com/apache/incubator-nuttx/
> pull/5513 <https://github.com/apache/incubator-nuttx/pull/5513>) so I
> tested it with HSMCI SD card interface. There are still some
> problems when I undef HSCMI_NOTXDMA at
> https://github.com/apache/incubator-
> nuttx/blob/master/arch/arm/src/samv7/sam_hsmci.c#L122
> <https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam_hsmci.c#L122>.
> The card unmounts
> itself as soon as I try to write to it with 'echo' command. I think this
> might be quite a different problem that can be sam_hsmci.c related as some
> other TX DMAs are working.
>
>
>
>
> I tested DMA with SPI and it works (althought I can write only to one half
> of the display but that might be some my problems in configuration if all
> your tests were fine) as well as DMA with USB device. I will take a look
> into HSCMI with DMA in the future, currently more critical problem for our
> implementation at Elektroline.cz company is DMA support for U(S)ART. That
> will also be a nice way to find if there are some further DMA TX bugs.
>
> Best regards,
> Michal Lenc
>
> -- Původní e-mail --
> Od: Simon Filgis 
> Komu: dev@nuttx.apache.org
> Datum: 14. 2. 2022 16:33:32
> Předmět: Re: SPI with DMA on SAME70
> "Dear all,
>
> I started to follow up this topic.
>
> Found that one in sam_hsmci.c:
>
> /* There is some unresolved issue with the SAMV7 DMA. TX DMA is currently
> * disabled.
> */
>
>
> #undef HSCMI_NORXDMA /* Define to disable RX DMA */
> *#define HSCMI_NOTXDMA 1 /* Define to disable TX DMA */*
>
>
> That fits my (and Michael Lenc's) experience that DMA peripheral to memory
> works. Memory to the peripheral seems broken though.
>
> I will therefore debug *sam_xdmax.c*. Even if I find some odd comments on
> DMA timeouts in sam_spi.c.
>
> If anybody has a better idea, or remembers details ;), please give
> feedback.
>
>
> BR,
>
> Simon
>
> --
> Hard- and Softwaredevelopment Consultant
> Ingenieurbüro-Filgis
> USt-IdNr.: DE305343278
>
>
> On Tue, Feb 8, 2022 at 11:52 AM Simon Filgis <
> si...@ingenieurbuero-filgis.de
> >
> wrote:
>
> > Dear all,
> >
> > I'm using ST7789.c in combination with lvgl-lib.
> >
> > The bottleneck to the display is the SPI communication. But even if I
> > increase the SPI frequency to 24MHz, it does not get faster. This is
> > because of constant delay between the bytes.
> >
> > I guessed that this can be improved using DMA. But that does not seem to
> > work out of the box. In the SPI TX callback the result of the DMA
> transfer
>
> > is -4. The transfer is not executed.
> >
> > Can anybody give me a hint on what to do?
> >
> > Best regards,
> >
> > Simon
> >
> > --
> > Hard- and Softwaredevelopment Consultant
> > Ingenieurbüro-Filgis
> > USt-IdNr.: DE305343278
> >
> "

Re: [Russia attacked Ukraine]

[Simon Filgis]

Stay save and take care, Petro!


Alan Carvalho de Assis  schrieb am Fr., 25. Feb. 2022,
18:04:

> I ask everyone here to reply directly to our friend Petro.
>
> BR,
>
> Alan
>
> On 2/25/22, Petro Karashchenko  wrote:
> > Hi,
> >
> > I know that this channel is not intended for things that I will write,
> but
> > I still will send this E-mail.
> >
> > For people that do not know: yesterday at 5AM Russia started massive
> > invasion and attacked Ukraine. The fightings are all over the central,
> > eastern, north and south. The bombs are exploding all over the country.
> > This is terrible. People are in fear. The war is in my country. We are
> > praying for peace and people to stop dying.
> >
> > At least knowing about this will be a support for my and my people's.
> >
> > Let Lord be with us,
> > Petro
> >
>

Re: SPI Example

[Simon Filgis]

Hi Roberto,

maybe Lup's article can help:

https://lupyuen.github.io/articles/spi2

Which platform do you use?

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Fri, Mar 4, 2022 at 8:41 AM Roberto Bucher 
wrote:

> Hi
>
> where can I found a simple example that send n bytes to the SPI and
> receive m bytes?
>
> I can now see the /dev/spi but using simple methods like open and write
> doesn't give me any signal on the bus...
>
> Thanks in advance
>
> Roberto
>
>

CAN FD - Baud-Rate Settings

[Simon Filgis]

Dear all,

I'm working on CAN-FD on SAME70Q21*A*. My tools claim a wrong checksum.
Therefore I suspect bittiming.

Has anybody a working config or can give me a link or tutorial how to set
those settings (never saw those segs for the fast data part):

[image: image.png]

Regards,

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278

Re: Apps: SQLite/Python on Nuttx

[Simon Filgis]

Hi Michael,

I'm interested in SQ-Light, but do not have any clue of status.

There is a newer PR for Micropython:
https://github.com/apache/incubator-nuttx-apps/pull/840

Best,

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Mon, Jun 20, 2022 at 8:51 AM  wrote:

> Dear all,
>
> I read, that SQLite was ported to Nuttx. Alan wrote that in a
> presentation in 2019
> (https://nuttx.events/wp-content/uploads/2019/11/AAssis_nx2019.pdf). But
> I cant find SQLite in the 10.0.3 sources.
>
> Could somebody give me a hint, where these port is? Or is there any work
> in progress, where I could start from? My intended platform would be the
> ESP32-WROVER with 8MB PSRAM. SQLite is under BSD license, what should be
> compatible to add it to Nuttx.
>
> About Python: there was in the past a uPython port for Nuttx, but it
> seems to be abandoned in 2016 or so. Is anybody working on a Python or
> uPython port to Nuttx?
>
> Thanks for any hint.
>

Syslog file max Size wrap issue

[Simon Filgis]

Dear nuttx developers,

I find the syslog architecture to generated files way bigger then
configured:

[image: image.png]

6 files of log-files with unpredictable final size, up to 1,5GB.

[image: image.png]

I would expect 10 files with maximum 0.5MB.

The file log stream is delegated to sd-card.

Does anybody face the same issue?


Happy new year,

Simon




--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Re: Syslog file max Size wrap issue

[Simon Filgis]

Hi Alan,

Thanks for your email.

I had a closer look and I think I do not think of a bug anymore.

Filesize is only checked once, while initializing the syslog file channel
with syslog_file_channel() at board level. In other words, rotation does
only happen on reboot.

A "life-rotate" mechanism would need to monitor log file size and do the
following:

sched_lock();
syslog_dev_uninitialize();
log_rotate();
syslog_dev_initialize();
syslog_channel();
sched_unlock();

This mechanism could live in a separate task
in drivers/syslog/syslog_filechannel.c or even at board level.
Or it could be triggered by each call of syslog() being addressed in the
depth of syslog.

As a first measure I reduced the log output of my application. It is
arguable if this "life-rotate" feature is of any real good in case you do
not have 1Gb log files by mistake.

Do you have any thoughts about this?

Simon

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Alan C. Assis  schrieb am So., 1. Jan. 2023, 14:01:

> Hi Simon,
>
> Happy new year!
>
> Do you know if that Rotating Log was working on previous releases (i.e
> 10.3) ?
>
> Probably some recent modification broke it.
>
> I think we don't have a Rotation Log test, we need some Software
> Qualification Testing when doing a software release.
>
> I just opened an Issue about it:
> https://github.com/apache/nuttx/issues/8017
>
> BR,
>
> Alan
>
> On 1/1/23, Simon Filgis  wrote:
> > Dear nuttx developers,
> >
> > I find the syslog architecture to generated files way bigger then
> > configured:
> >
> > [image: image.png]
> >
> > 6 files of log-files with unpredictable final size, up to 1,5GB.
> >
> > [image: image.png]
> >
> > I would expect 10 files with maximum 0.5MB.
> >
> > The file log stream is delegated to sd-card.
> >
> > Does anybody face the same issue?
> >
> >
> > Happy new year,
> >
> > Simon
> >
> >
> >
> >
> > --
> > Ingenieurbüro-Filgis
> > USt-IdNr.: DE305343278
> > --
> > sent by mobile phone
> >
>

Re: initial gpio state: power on -> boot -> rtos -> app.

[Simon Filgis]

Not to forget to consider the time between reset and first init. Default
pin state mostly is input floating, or input weak pull-up.

Don't let big bang happen that early.

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Nathan Hartman  schrieb am So., 19. Feb. 2023,
13:13:

> On Sat, Feb 18, 2023 at 11:48 PM Tomek CEDRO  wrote:
>
> > Hello world :-)
> >
> > I am working on a pretty industrial automation project right now that
> > will control 3 phase motor over 400V/25A relays.
> >
> > There are 6 relays to provide all possible modes of 3 phase motor
> > control. There are 3 groups of two relays for a task like direction
> > change, star-left-star-right, and star-triangle switch. Each two of
> > the relays in the group will have exclusive control (i.e. when one is
> > on the other will have control cut off). But there groups are not
> > fully exclusive physically due to their function. So when all three
> > groups are turned on then big bang happens :-)
> >
> > I am still wondering how to protect against this big bang. For sure I
> > will add some physical protection so this situation is impossible
> > (i.e. some sort of logic between GPIO and relays where only one line
> > will indicate possible safe operation state of all relays, while zero
> > or more than one line set high will always result in a safe state).
> >
> > This lead me to think of the initial state of the ESP32 GPIO pins
> > after boot then after NuttX starts.. or when device will be in
> > bootloader / flashing state.. in case of malfunction.. or malicious
> > actions (it might be connected to the internet somehow).. or simply
> > sending 0x to /dev/gpio0 etc etc?
> >
> > My question is: it is possible to be sure of the GPIO pin state since
> > power-on through bootloader + RTOS up to the application run? For
> > instance not to let all pins go high/low/random?
> >
> > Any hints welcome :-)
> > Tomek
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >
>
> Rather than use the default GPIO driver, I would probably consider a custom
> driver that doesn't present to applications as individual GPIO pins, but
> rather as higher level constructs (motor off, star-left, star-right, etc),
> with mappings to specific GPIO pins in board.h. That custom driver would
> initialize the actual pins to the safe state (motor off) on boot, would
> return the pins to that state when the driver is closed, and would produce
> only allowed combinations of GPIO outputs.
>
> In addition, never trust software when it could cause real-world big bangs!
> Since industrial controls must be connected to a safety controller
> (emergency stop or "E Stop"), that can put the entire machine or line in a
> safe state, I would design logic on the circuit board that E-stops the
> system if: (1) any forbidden combination of GPIOs is ever output, or (2) a
> hardware watchdog that ensures the software hasn't frozen.
>
> Cheers
> Nathan
>

Re: initial gpio state: power on -> boot -> rtos -> app.

[Simon Filgis]

Hi Tomek,

1s keepalive can also be addressed with sw-watchdog. It may be easier than
flipflopping.

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Mon, Feb 20, 2023 at 3:08 PM Tomek CEDRO  wrote:

> On Mon, Feb 20, 2023 at 2:52 PM Tomek CEDRO wrote:
> > In a more complex design I think that dedicated logic is required
> > between mcu and the acuators that would verify working state with some
> > sort of latching that prevents accidental fires :-)
>
> In addition to machine-state-awareness, even safer than latching would
> be keepalive control clocking, so logic will only set a valid working
> acuator state for a short period of time (i.e. 1s) until it gets
> another command or gets back to a safe state (stop), mcu must send
> desired command soon enough (i.e. 1/2s) in order to perform continuous
> actions.
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: initial gpio state: power on -> boot -> rtos -> app.

[Simon Filgis]

Hi Tomek,
I mean MCU peripheral watchdog just for clarification. Not a sw-watchdog
flow control. But is that available in the nuttx codebase btw?
:)

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Mon, Feb 20, 2023 at 3:24 PM Tomek CEDRO  wrote:

> On Mon, Feb 20, 2023 at 3:12 PM Simon Filgis wrote:
> > 1s keepalive can also be addressed with sw-watchdog. It may be easier
> than
> > flipflopping.
>
> Thanks Simon! I was also thinking about custom NuttX driver as Nathan
> suggested.. I need to see how complex is that.. always want to learn
> new stuff.. I will start from reading the sw-watchdog code :-) :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: Bitbucket Pipeline - romfs failure

[Simon Filgis]

Hi Alan,

my custom board. It compiles well on my computer. Romfs fails only the
bitbucket pipe docker. How can I check if the generation was successful? In
the log, it looks fine, doesn't it?

Simon


--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Thu, Feb 23, 2023 at 3:27 PM Alan C. Assis  wrote:

> Hi Simon,
>
> What board and board profile are you using?
>
> This error normally happens when genromfs didn't generated the romfs image.
>
> BR,
>
> Alan
>
> On 2/23/23, Simon Filgis  wrote:
> > Dear all,
> >
> > I'm setting up a build-pipeline in bitbucket. It fails with:
> > arm-none-eabi-ld:
> >
> /opt/atlassian/pipelines/agent/build/nuttx/staging/libapps.a(nsh_romfsetc.c.opt.atlassian.pipelines.agent.build.apps.nshlib.o):
> > in function `nsh_romfsetc':
> > 3126
> > /opt/atlassian/pipelines/agent/build/apps/nshlib/nsh_romfsetc.c:97:
> > undefined reference to `romfs_img_len'
> > 3127
> > arm-none-eabi-ld:
> > /opt/atlassian/pipelines/agent/build/apps/nshlib/nsh_romfsetc.c:97:
> > undefined reference to `romfs_img'
> > 3128
> > make[1]: *** [Makefile:159: nuttx] Error 1
> >
> > Has anybody a hint or idea howto overcome this?
> >
> > Simon
> >
> > --
> > Hard- and Softwaredevelopment Consultant
> > Ingenieurbüro-Filgis
> > USt-IdNr.: DE305343278
> >
>

Re: Bitbucket Pipeline - romfs failure

[Simon Filgis]

Hi Alan,

many thanks:

xxd -i romfs.img | sed -e "s/^unsigned char/const unsigned char
aligned_data(4)/g" >> etctmp.c
/bin/sh: 1: xxd: not found
rm romfs.img


xxd is part of vim-common. Now it works.

Should we add vim-common to the list of dependencies, or is this a corner
case?

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Thu, Feb 23, 2023 at 10:22 PM Alan C. Assis  wrote:

> Hi Simon,
>
> Please try to compile with verbose enabled:
>
> make V=1
>
> It could disclose more information about the issue.
>
> BR,
>
> Alan
>
> On 2/23/23, Simon Filgis  wrote:
> > Hi Alan,
> >
> > my custom board. It compiles well on my computer. Romfs fails only the
> > bitbucket pipe docker. How can I check if the generation was successful?
> In
> > the log, it looks fine, doesn't it?
> >
> > Simon
> >
> >
> > --
> > Hard- and Softwaredevelopment Consultant
> > Ingenieurbüro-Filgis
> > USt-IdNr.: DE305343278
> >
> >
> > On Thu, Feb 23, 2023 at 3:27 PM Alan C. Assis  wrote:
> >
> >> Hi Simon,
> >>
> >> What board and board profile are you using?
> >>
> >> This error normally happens when genromfs didn't generated the romfs
> >> image.
> >>
> >> BR,
> >>
> >> Alan
> >>
> >> On 2/23/23, Simon Filgis  wrote:
> >> > Dear all,
> >> >
> >> > I'm setting up a build-pipeline in bitbucket. It fails with:
> >> > arm-none-eabi-ld:
> >> >
> >>
> /opt/atlassian/pipelines/agent/build/nuttx/staging/libapps.a(nsh_romfsetc.c.opt.atlassian.pipelines.agent.build.apps.nshlib.o):
> >> > in function `nsh_romfsetc':
> >> > 3126
> >> > /opt/atlassian/pipelines/agent/build/apps/nshlib/nsh_romfsetc.c:97:
> >> > undefined reference to `romfs_img_len'
> >> > 3127
> >> > arm-none-eabi-ld:
> >> > /opt/atlassian/pipelines/agent/build/apps/nshlib/nsh_romfsetc.c:97:
> >> > undefined reference to `romfs_img'
> >> > 3128
> >> > make[1]: *** [Makefile:159: nuttx] Error 1
> >> >
> >> > Has anybody a hint or idea howto overcome this?
> >> >
> >> > Simon
> >> >
> >> > --
> >> > Hard- and Softwaredevelopment Consultant
> >> > Ingenieurbüro-Filgis
> >> > USt-IdNr.: DE305343278
> >> >
> >>
> >
>

Re: Bitbucket Pipeline - romfs failure

[Simon Filgis]

Hi,

I changed to xxd instead of vim-common. Makes more sense. Thanks Petro.

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Fri, Feb 24, 2023 at 2:16 PM Alan C. Assis  wrote:

> Hi Pedro and Simon,
>
> I submitted a patch to include xxd in our documentation.
>
> BR,
>
> Alan
>
> On 2/24/23, Petro Karashchenko  wrote:
> > Hello Simon,
> >
> > Maybe adding "apt-get install -y xxd" -- I mean adding xxd separately
> > instead of vim-common and let package manager to resolve dependencies is
> a
> > better approach?
> >
> > Best regards,
> > Petro
> >
> > пт, 24 лют. 2023 р. о 10:46 Simon Filgis  >
> > пише:
> >
> >> Hi Alan,
> >>
> >> many thanks:
> >>
> >> xxd -i romfs.img | sed -e "s/^unsigned char/const unsigned char
> >> aligned_data(4)/g" >> etctmp.c
> >> /bin/sh: 1: xxd: not found
> >> rm romfs.img
> >>
> >>
> >> xxd is part of vim-common. Now it works.
> >>
> >> Should we add vim-common to the list of dependencies, or is this a
> corner
> >> case?
> >>
> >> Simon
> >>
> >> --
> >> Hard- and Softwaredevelopment Consultant
> >> Ingenieurbüro-Filgis
> >> USt-IdNr.: DE305343278
> >>
> >>
> >> On Thu, Feb 23, 2023 at 10:22 PM Alan C. Assis 
> wrote:
> >>
> >> > Hi Simon,
> >> >
> >> > Please try to compile with verbose enabled:
> >> >
> >> > make V=1
> >> >
> >> > It could disclose more information about the issue.
> >> >
> >> > BR,
> >> >
> >> > Alan
> >> >
> >> > On 2/23/23, Simon Filgis  wrote:
> >> > > Hi Alan,
> >> > >
> >> > > my custom board. It compiles well on my computer. Romfs fails only
> >> > > the
> >> > > bitbucket pipe docker. How can I check if the generation was
> >> successful?
> >> > In
> >> > > the log, it looks fine, doesn't it?
> >> > >
> >> > > Simon
> >> > >
> >> > >
> >> > > --
> >> > > Hard- and Softwaredevelopment Consultant
> >> > > Ingenieurbüro-Filgis
> >> > > USt-IdNr.: DE305343278
> >> > >
> >> > >
> >> > > On Thu, Feb 23, 2023 at 3:27 PM Alan C. Assis 
> >> wrote:
> >> > >
> >> > >> Hi Simon,
> >> > >>
> >> > >> What board and board profile are you using?
> >> > >>
> >> > >> This error normally happens when genromfs didn't generated the
> romfs
> >> > >> image.
> >> > >>
> >> > >> BR,
> >> > >>
> >> > >> Alan
> >> > >>
> >> > >> On 2/23/23, Simon Filgis  wrote:
> >> > >> > Dear all,
> >> > >> >
> >> > >> > I'm setting up a build-pipeline in bitbucket. It fails with:
> >> > >> > arm-none-eabi-ld:
> >> > >> >
> >> > >>
> >> >
> >>
> /opt/atlassian/pipelines/agent/build/nuttx/staging/libapps.a(nsh_romfsetc.c.opt.atlassian.pipelines.agent.build.apps.nshlib.o):
> >> > >> > in function `nsh_romfsetc':
> >> > >> > 3126
> >> > >> >
> /opt/atlassian/pipelines/agent/build/apps/nshlib/nsh_romfsetc.c:97:
> >> > >> > undefined reference to `romfs_img_len'
> >> > >> > 3127
> >> > >> > arm-none-eabi-ld:
> >> > >> >
> /opt/atlassian/pipelines/agent/build/apps/nshlib/nsh_romfsetc.c:97:
> >> > >> > undefined reference to `romfs_img'
> >> > >> > 3128
> >> > >> > make[1]: *** [Makefile:159: nuttx] Error 1
> >> > >> >
> >> > >> > Has anybody a hint or idea howto overcome this?
> >> > >> >
> >> > >> > Simon
> >> > >> >
> >> > >> > --
> >> > >> > Hard- and Softwaredevelopment Consultant
> >> > >> > Ingenieurbüro-Filgis
> >> > >> > USt-IdNr.: DE305343278
> >> > >> >
> >> > >>
> >> > >
> >> >
> >>
> >
>

Re: W25Nx NAND flash support

[Simon Filgis]

Hi Michael,

In addition, if you want to load your elf directly to the memory mapped
flash storage, you need some flashloader for your debug tool. I can help
with segger's flashloader if that is of interest. (dsk)
https://www.segger.com/products/debug-probes/j-link/technology/j-link-dsk/

Simon

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Alan C. Assis  schrieb am Sa., 25. Feb. 2023, 14:29:

> Hi Michal,
>
> There is some discussion about it here:
> https://www.mail-archive.com/dev@nuttx.apache.org/msg04981.html
>
> and here:
> https://lists.apache.org/thread/kh5t6fn24q97d3qxzthksld4l3jtw27c
>
> In a nutshell:
>
> 1) If parallel NAND Flash is used your MCU will need first the NAND
> Flash controller driver. SPI and QSPI NAND are different story;
> 2) NuttX needs the basic NAND Bad-Block search function infrastructure
> (look nand_devscan() is not updating the bad-block table)
> 3) NuttX needs a File System able to handle NAND Flash
>
> Currently there is no FS on NuttX able to handle NAND.
> So you can port the CHFS from NetBSD or take a look at dhara
> (https://github.com/dlbeer/dhara).
>
> Maybe LittleFS or SmartFS could be extended to handle NAND.
>
> BR,
>
> Alan
>
> On 2/25/23, Michal Lenc  wrote:
> > Hello,
> >
> >
> >
> > I am looking into usage of w25nx NAND flash communicating over QSPI. What
> > is
> > the current support of NAND flash memories in NuttX? I found out some
> > warnings in drivers/mtd/README.txt regarding the lack of a file system
> that
> >
> > could handle NAND memories but I am not sure if they are still actual or
> > those problems were solved. There are some header files and source code
> > files for NAND memory support but some of them seem to be incomplete
> (like
> > nand_initialize() function for example
> > https://github.com/apache/nuttx/blob/
> > master/include/nuttx/mtd/nand.h#L105).
> >
> >
> >
> >
> > Would the implementation of w25nx flash require some further involvement
> in
> >
> > file system support or just the implementation of w25nx driver itself
> > (similar to already implemented w25q NOR flash)?
> >
> >
> >
> >
> > Thanks.
> >
> > Best regards,
> > Michal Lenc
> >
>

Manjaro Distro

[Simon Filgis]

Dear all,

I switched to Manjaro a few weeks ago. Now I'm trying to build NuttX - of
course.

This packages where necessary so far:

sudo pacman -S ncurses base-devel gmp mpfr libisl elfutils expat
lib32-gcc-libs uboot-tools unzip


# Install genromfs as per PX4

wget
https://sourceforge.net/projects/romfs/files/genromfs/0.5.2/genromfs-0.5.2.tar.gz
tar zxvf genromfs-0.5.2.tar.gz
cd genromfs-0.5.2 && make && make install && cd ..
rm genromfs-0.5.2.tar.gz genromfs-0.5.2 -r


--

I cannot resolve the following error:
fatal error: math.h: No such file or directory

NuttX documentation says:

The math library header file, `math.h`, is a then special case.  If you do
nothing, the standard math.h header file that is provided with your
toolchain will be used.


Can somebody please give me a hint for how to overcome this?

Best regards,

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278

Re: Manjaro Distro

[Simon Filgis]

Hi all,

thanks for answering.

I'm still in build-phase. No runtime hard-fault. I'm using my fork on
github https://github.com/SimonFilgis/incubator-nuttx

Mr. Xiao nailed it. It choose to use the NuttX internal libm for the moment.

But still something seems to miss, please have a look at the attached log.

LD: nuttx
> arm-none-eabi-ld --entry=__start -nostdlib --gc-sections --cref
> -Map=/home/simon/projects/autococo2/temp/autococo2fw/nuttx/nuttx.map -g
> -T/home/simon/projects/autococo2/temp/autococo2fw/nuttx/../autococo2-board/scripts/flash.ld
>  -L /home/simon/projects/autococo2/temp/autococo2fw/nuttx/staging -L
> /home/simon/projects/autococo2/temp/autococo2fw/nuttx/arch/arm/src/board  \
> -o /home/simon/projects/autococo2/temp/autococo2fw/nuttx/nuttx   \
> --start-group -lsched -ldrivers -lboards -lc -lmm -larch -lapps
> -lnet -lfs -lbinfmt -lboard
> /usr/lib/gcc/arm-none-eabi/12.2.0/thumb/v7e-m+dp/hard/libgcc.a --end-group
> arm-none-eabi-ld: warning:
> /home/simon/projects/autococo2/temp/autococo2fw/nuttx/nuttx has a LOAD
> segment with RWX permissions
> arm-none-eabi-ld:
> /home/simon/projects/autococo2/temp/autococo2fw/nuttx/staging/libapps.a(nsh_romfsetc.c.home.simon.projects.autococo2.temp.autococo2fw.apps.nshlib.o):
> in function `nsh_romfsetc':
> /home/simon/projects/autococo2/temp/autococo2fw/apps/nshlib/nsh_romfsetc.c:97:
> undefined reference to `romfs_img_len'
> arm-none-eabi-ld:
> /home/simon/projects/autococo2/temp/autococo2fw/apps/nshlib/nsh_romfsetc.c:97:
> undefined reference to `romfs_img'
> make[1]: *** [Makefile:159: nuttx] Error 1
> make[1]: Leaving directory
> '/home/simon/projects/autococo2/temp/autococo2fw/nuttx/arch/arm/src'
> make: *** [tools/Unix.mk:509: nuttx] Error 2
>

Again romfs_img, I had this with the bitbucket pipeline a few days ago, xxd
was missing. I cannot identify root cause with make V=1 (attached).

Has anybody an idea?

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Wed, Mar 8, 2023 at 7:43 PM Gregory Nutt  wrote:

>
> > Hi,
> >
> > I think that some key information is missing like what is the NuttX
> version
> > used. Is it mainline or some release or custom.
> >
> > Best regards,
> > Petro
>
> It would be helpful to understand where and why the crash occurs too.
> You can get that information by analyzing the stack.  See
>
> https://cwiki.apache.org/confluence/display/NUTTX/Analyzing+Cortex-M+Hardfaults
> for an example.
>
> Without know why the hard fault occurs that is nothing anyone can really
> do or say to be helpful (unless the problem can be replicated).
>
>

Re: MCU/Board with WiFi, BT and USB Host

[Simon Filgis]

Yes, answer is not no. I heard about 10k for "registering" a product with
certified module. So no measurements, only paperwork.

I would be glad to hear that's wrong! It feels wrong definitely...

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Tomek CEDRO  schrieb am Do., 20. Apr. 2023, 21:51:

> On Thu, Apr 20, 2023 at 9:42 PM Tim Hardisty wrote:
> > To the best of my understanding, using a module does NOT mean you can
> avoid certification for a custom board that uses it. I am a member of the
> SIG and specifically asked this…but they do not give a 100% clear answer ☹️
>
> whaaat o_O
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: Odd DMA issue

[Simon Filgis]

D-Cache flush?

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Tim Hardisty  schrieb am Mi., 17. Mai 2023, 20:05:

> I am working on getting DMA working on the SPI peripheral of the SAMA5D2.
>
> DMA reads now work well, but the writes take absolutely forever…unless I
> have dma debug info enabled, when write transactions (to a GD25Q flash) do
> then work.
>
> I’m working through it, as it sounds like a race condition or other
> timing/sequence problem but if anyone by any chance has encountered
> anything similar, clues or suggestions would be most welcome!
>
> Thx,
>
> Tim
>

Re: Odd DMA issue

[Simon Filgis]

Hi Tim,

Cache flush after dma data copy was a hard nut we had. But it was on read,
you face issues on write, I was to fast.

Maybe this samv7 PR helps also on your arch:

https://github.com/apache/nuttx/pull/5513

Simon

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Tim Hardisty  schrieb am Mi., 17. Mai 2023, 20:31:

> Good suggestion – thanks!
>
> From: Petro Karashchenko 
> Reply to: "dev@nuttx.apache.org" 
> Date: Wednesday, 17 May 2023 at 19:28
> To: "dev@nuttx.apache.org" 
> Subject: Re: Odd DMA issue
>
> I think you can try to compare versus SAMv7 SPI+DMA driver that is working
> well and see if there are obvious differences.
>
> BR,
> Petro
>
> On Wed, May 17, 2023, 9:18 PM Simon Filgis  <mailto:si...@ingenieurbuero-filgis.de>>
> wrote:
>
> D-Cache flush?
>
> --
> Ingenieurbüro-Filgis
> USt-IdNr.: DE305343278
> --
> sent by mobile phone
>
> Tim Hardisty mailto:t...@hardisty.co.uk>> schrieb am
> Mi., 17. Mai 2023, 20:05:
>
> > I am working on getting DMA working on the SPI peripheral of the SAMA5D2.
> >
> > DMA reads now work well, but the writes take absolutely forever…unless I
> > have dma debug info enabled, when write transactions (to a GD25Q flash)
> do
> > then work.
> >
> > I’m working through it, as it sounds like a race condition or other
> > timing/sequence problem but if anyone by any chance has encountered
> > anything similar, clues or suggestions would be most welcome!
> >
> > Thx,
> >
> > Tim
> >
>
>
>

OpenFLASHLoader

[Simon Filgis]

Dear all,

I need to load an FPGA bitstream via JTAG bitbang.

In my case the straight way would be to use the lattice embeddedvm (ispVM)
but I'm wondering if there is something more generic out there. Like
OpenFPGALoader.

What do you think?

Regards,

Simon

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Re: OpenFPGALoader

[Simon Filgis]

Sorry, I have a typo in the subject.

Not FLASHLoader but FPGALoader.

https://github.com/trabucayre/openFPGALoader

The Segger Flashloader has been used by me already. Funny piece of software
but not for FPGA...

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Xiang Xiao  schrieb am Do., 13. Juli 2023, 17:23:

> If you are using JLINK, you may implement a general flash programer by
> reusing NuttX flash driver:
> https://wiki.segger.com/SEGGER_Flash_Loader
>
> On Thu, Jul 13, 2023 at 10:51 PM Simon Filgis <
> si...@ingenieurbuero-filgis.de> wrote:
>
> > Dear all,
> >
> > I need to load an FPGA bitstream via JTAG bitbang.
> >
> > In my case the straight way would be to use the lattice embeddedvm
> (ispVM)
> > but I'm wondering if there is something more generic out there. Like
> > OpenFPGALoader.
> >
> > What do you think?
> >
> > Regards,
> >
> > Simon
> >
> > --
> > Ingenieurbüro-Filgis
> > USt-IdNr.: DE305343278
> > --
> > sent by mobile phone
> >
>

Re: OpenFPGALoader

[Simon Filgis]

Resending without attachment...

Simon Filgis  schrieb am Do., 13. Juli
2023, 18:38:

> Hi Alan,
>
> Indeed the ICE fpgas are loaded by SPI. Interesting.
>
> But mine is loaded by JTAG.
>
> Every FPGA vendor has a "player" to bitbang their svf out of the
> microcontroller.
>
> OpenFPGALoader is the most sophisticated approach I found sofar. I doubt
> it is easy to port it. Is anybody willing to help me with trying?
>
> Regards,
>
> Simon
>
> --
> Ingenieurbüro-Filgis
> USt-IdNr.: DE305343278
> --
> sent by mobile phone
>
> Alan C. Assis  schrieb am Do., 13. Juli 2023, 18:13:
>
>> Hi Simon,
>>
>> I didn't look the code, but openFPGALoader is implemented in C++ and I
>> don't know if they are using features that don't fit well to
>> microcontrollers.
>>
>> So, the only way to confirming if it works is trying to compile and run
>> it.
>>
>> If you only need to use FPGAs from Lattice, maybe you can try to SPI
>> iceboot approach:
>>
>> https://github.com/al177/blinkencard/blob/master/micropython/iceboot.py
>>
>> (disclaimer: I don't know much about FPGAs yet)
>>
>> BR,
>>
>> Alan
>>
>> On 7/13/23, Simon Filgis  wrote:
>> > Sorry, I have a typo in the subject.
>> >
>> > Not FLASHLoader but FPGALoader.
>> >
>> > https://github.com/trabucayre/openFPGALoader
>> >
>> > The Segger Flashloader has been used by me already. Funny piece of
>> software
>> > but not for FPGA...
>> >
>> > --
>> > Ingenieurbüro-Filgis
>> > USt-IdNr.: DE305343278
>> > --
>> > sent by mobile phone
>> >
>> > Xiang Xiao  schrieb am Do., 13. Juli 2023,
>> > 17:23:
>> >
>> >> If you are using JLINK, you may implement a general flash programer by
>> >> reusing NuttX flash driver:
>> >> https://wiki.segger.com/SEGGER_Flash_Loader
>> >>
>> >> On Thu, Jul 13, 2023 at 10:51 PM Simon Filgis <
>> >> si...@ingenieurbuero-filgis.de> wrote:
>> >>
>> >> > Dear all,
>> >> >
>> >> > I need to load an FPGA bitstream via JTAG bitbang.
>> >> >
>> >> > In my case the straight way would be to use the lattice embeddedvm
>> >> (ispVM)
>> >> > but I'm wondering if there is something more generic out there. Like
>> >> > OpenFPGALoader.
>> >> >
>> >> > What do you think?
>> >> >
>> >> > Regards,
>> >> >
>> >> > Simon
>> >> >
>> >> > --
>> >> > Ingenieurbüro-Filgis
>> >> > USt-IdNr.: DE305343278
>> >> > --
>> >> > sent by mobile phone
>> >> >
>> >>
>> >
>>
>

Re: OpenFPGALoader

[Simon Filgis]

LFE5U-25F-8BG381C

with attached SPI Flash: AT25SF161B-MHB

Lattice Diamond Deployment tool generates SVF or VME files...

I'm just wondering if I should go for something more generic than the
Lattice ispVM (quite old piece of code)

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Thu, Jul 13, 2023 at 7:04 PM Frank-Christian Kruegel 
wrote:

> Am 13.07.2023 um 18:52 schrieb Simon Filgis:
>
> >> Indeed the ICE fpgas are loaded by SPI. Interesting.
> >>
> >> But mine is loaded by JTAG.
>
> What FPGA type do you use EXACTLY?
>
> Frank-Christian
>
>

Re: OpenFPGALoader

[Simon Filgis]

Hi Alan, yes, that's ispVM.

The original from Lattice can be found in the installation folder of
Lattice Diamond SW.
usr/local/programmer/diamond/3.12/embedded_source/vmembedded/sourcecode/ispvme/

That is one way for Lattice!

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Thu, Jul 13, 2023 at 7:24 PM Alan C. Assis  wrote:

> Hi Simon,
>
> ispVM is pure C:
> https://github.com/ganehag/br-ts7500/blob/master/ts7500utils/ispvm.c
>
> Could be easier to get working on NuttX than openFPGALoader, although
> to latter will open doors to many vendors!
>
> BR,
>
> Alan
>
> On 7/13/23, Simon Filgis  wrote:
> > LFE5U-25F-8BG381C
> >
> > with attached SPI Flash: AT25SF161B-MHB
> >
> > Lattice Diamond Deployment tool generates SVF or VME files...
> >
> > I'm just wondering if I should go for something more generic than the
> > Lattice ispVM (quite old piece of code)
> >
> > Simon
> >
> > --
> > Hard- and Softwaredevelopment Consultant
> > Ingenieurbüro-Filgis
> > USt-IdNr.: DE305343278
> >
> >
> > On Thu, Jul 13, 2023 at 7:04 PM Frank-Christian Kruegel  >
> > wrote:
> >
> >> Am 13.07.2023 um 18:52 schrieb Simon Filgis:
> >>
> >> >> Indeed the ICE fpgas are loaded by SPI. Interesting.
> >> >>
> >> >> But mine is loaded by JTAG.
> >>
> >> What FPGA type do you use EXACTLY?
> >>
> >> Frank-Christian
> >>
> >>
> >
>

fat32 sd-card filesystem broken

[Simon Filgis]

Dear all,

Once in a while nuttx breaks the fat32 filesystem of my sd-card.

Custom fork, around 1 year old. samv7, DMA enabled.

I have syslog to sd-card enabled. Also a FTP server accepts files to
sd-card.

Has anybody observed something similar? How to start debugging such an
issue?

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278

Re: different IP than expected

[Simon Filgis]

When I started with networking, I set the IP via kconfig. I remember that
it was necessary to enter the same IP at two different places. Netlib and
FTP server in my case. Maybe your IP is overwritten by another app? A
buildin app that you use for experiments?

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Gregory Nutt  schrieb am Do., 21. Sept. 2023, 14:21:

>
> On 9/21/2023 5:06 AM, Gustavo Soares wrote:
> > Why is it a different IP? The server is listening to one but this
> > method returns another one.
>
> You provide almost no information for anyone to really help you.
>
> Where is the server and client?  It sounds like you are saying that the
> HTTP server is on some remote platform.  Is that right? The client logic
> is on the NuttX target, correct?
>
> You seem to be saying that you connect to the remote server, then do an
> HTTP GET.  The remote IP address in the returned message is not the same
> as the IP address that you connected to.  That is what I am hearing.
>
> What does this have to do with NuttX?  I suggest that you run some
> sniffer like WireShark so you can see what the real point-to-point
> traffic.  The content returned to NuttX has nothing to do with NuttX.
>
> Or have I got that wrong.  You need to communicate more.
>
>

Re: ESP32 I2S audio recording is incomplete

[Simon Filgis]

Hi Simona,

SD Cards have busy time times of 500ms max (per spec) for saving data
internally. I saw SD Cards taking over a second of busy time.

You can check with the Oszilloskop. I think data0 is the pin that signalize
busy...

Per design, you need a stream buffer that can handle your audio stream up
to 500ms...

Regards,

Simon

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Alan C. Assis  schrieb am Do., 19. Okt. 2023, 23:36:

> Hi Simona,
>
> On 10/19/23, Simona Toaca  wrote:
> > Hello,
> > I am trying to record audio using a MEMS microphone, but the final
> > recording is missing parts periodically (for example, with a sample rate
> of
> > 8kHz, there are parts ~1s long missing once every ~10-11s. Using a sample
> > rate of 48kHz, the period is ~1s long). This is my first time working
> with
> > I2S and I can't figure out what causes this behaviour.
> >
> > My setup is as follows:
> > - the microphone has 24-bit depth in a 32-bit word (MSB first) when
> > transmitting data
> > - i am using nxrecorder to record the pcm audio onto an SD card (device
> > pcm_in0)
> > - to listen to the recording i import the file into Audacity (24-bit, Big
> > Endian)
> >
> > Defconfig regarding audio:
> > CONFIG_AUDIO=y
> > CONFIG_AUDIO_BUFFER_NUMBYTES=6144 (from the i2s buffer which is 8192
> bytes,
> > 3/4 of it is "useful" info, 6144 bytes in total)
> > CONFIG_AUDIO_DMA=y
> > CONFIG_AUDIO_FORMAT_RAW=y
> > CONFIG_AUDIO_I2S=y
> > CONFIG_DMA=y
> > CONFIG_DMA_LINK=y
> > CONFIG_DRIVERS_AUDIO=y
> > CONFIG_ESP32_I2S0=y
> > CONFIG_ESP32_I2S0_BCLKPIN=25
> > CONFIG_ESP32_I2S0_DATA_BIT_WIDTH_24BIT=y
> > CONFIG_ESP32_I2S0_DINPIN=26
> > CONFIG_ESP32_I2S0_SAMPLE_RATE=8000
> > CONFIG_ESP32_I2S0_WSPIN=27
> > CONFIG_ESP32_I2S=y
> > CONFIG_I2S_DMADESC_NUM=4
> >
> > I tried modifying the number of audio buffers and also making them
> bigger,
> > but that did not solve the problem.
> > Any ideas on what could cause this?
> >
>
> Could it be something related to SDCard storage? Maybe it needs some
> optimization!
>
> Please try using a RAMDISK of 1MB+ and save the file to it.
>
> If it works we will know the SDCard could be the limitation of this
> configuration.
>
> BR,
>
> Alan
>

Re: Networking Delay: SO_SNDTIMEO odd behavior

[Simon Filgis]

Hi Hakeem,

do you build for armv7/v8?

Do you have:
https://github.com/apache/nuttx/pull/10536

It solves 1s random timeout for me. Without my app works due to
retransmission request, but with some 1s delays.

Simon

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Nathan Hartman  schrieb am Di., 28. Nov. 2023,
15:41:

> On Tue, Nov 28, 2023 at 3:58 AM Alan C. Assis  wrote:
>
> > Hi Hakeem,
> >
> > Thank you very much for reporting an issue your team found.
> >
> > Could you please open an issue with more information at
> > https://github.com/apache/nuttx/issues and supply a little bit more
> > information (board/mcu used, version of NuttX, host OS, etc).
> >
> > Please also supply your board config (run "make savedefconfig" and
> > attach the defconfig generated).
>
>
>
> Also please specify which version of NuttX you are using -- is it a
> released tarball and if so which version, or is it a clone from git and if
> so is it the latest available master?
>
> Thanks
> Nathan
>

STM32H7 board with ethernet

[Simon Filgis]

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

[Simon Filgis]

Hi Sebastien,

I have NUCLEO-H755ZI-Q on my table, but could not find a board package in
the tree. Is it supported?

Regards,

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Tue, Feb 6, 2024 at 10:34 AM Sebastien Lorquet 
wrote:

> Hi,
>
> The nucleo-h7 board series definitely work, there are several models
> with ethernet.
>
> Sebastien
>
>
> Le 06/02/2024 à 10:26, Simon Filgis a écrit :
> > 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

[Simon Filgis]

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

[Simon Filgis]

Dear all,

I'm back at the board (NUCLEO-H743ZI2). Using latest master (with
https://github.com/apache/nuttx/commit/31817335e453eec65e8f5d1163c32efd5da373cb)
and pysim config is stable.

But I am not able to ping. I tried the following setups:
PC <-> Nucleo-Board
PC <-> Switch <-> Nucleo-Board

*Here the output from the board:*
nsh> ping 192.168.178.1
PING 192.168.178.1 56 bytes of data
No response from 192.168.178.1: icmp_seq=0 time=1000 ms
No response from 192.168.178.1: icmp_seq=1 time=1000 ms
No response from 192.168.178.1: icmp_seq=2 time=1000 ms
No response from 192.168.178.1: icmp_seq=3 time=1000 ms
No response from 192.168.178.1: icmp_seq=4 time=1000 ms
No response from 192.168.178.1: icmp_seq=5 time=1000 ms
No response from 192.168.178.1: icmp_seq=6 time=1000 ms
No response from 192.168.178.1: icmp_seq=7 time=1000 ms
No response from 192.168.178.1: icmp_seq=8 time=1000 ms
No response from 192.168.178.1: icmp_seq=9 time=1000 ms
10 packets transmitted, 0 received, 100% packet loss, time 10010 ms
nsh> ifconfig
eth0Link encap:Ethernet HWaddr 02:55:10:e5:49:a2 at UP mtu 1486
inet addr:192.168.178.5 DRaddr:192.168.178.1 Mask:255.255.255.0

lo  Link encap:Local Loopback at RUNNING mtu 1518
inet addr:127.0.0.1 DRaddr:127.0.0.1 Mask:255.0.0.0

 IPv4   TCP   UDP  ICMP
Received *0020*    001e     *--> there seems to be some traffic*
Dropped  0002      
  IPv4VHL:    Frg: 
  Checksum         
  TCP ACK:    SYN: 
  RST:   
  Type         
Sent 000a      000a
  Rexmit       
nsh>

*And the output of the PC:*
ping 192.168.178.5
PING 192.168.178.5 (192.168.178.5) 56(84) bytes of data.
>From 192.168.178.1 icmp_seq=1 Destination Host Unreachable
>From 192.168.178.1 icmp_seq=2 Destination Host Unreachable

 What could it be that I'm doing wrong? Is using DHCP mandatory with this
config? I set a initial IP adress via menuconfig and I also tried with
ifconfig eth0 192

Thanks for your help,

Simon

--
Hard- and Softwaredevelopment Consultant
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278


On Wed, Feb 7, 2024 at 10:58 AM Roberto Bucher <
roberto.bucher.2...@gmail.com> wrote:

> I did some tests and sometimes it works and sometimes (the most
> times...) it gives the error...
>
> The error usually appears when I give the command
>
> nsh> ifconfig
>
> or
>
> nsh> renew eth0
>
> but not all the times. I think that it can be a problem with memory
> sizes; I'll try more investigations
>
> BR
>
> Roberto
>
> NuttShell (NSH) NuttX-12.4.0-RC0
> nsh> ping 192.168.1.155
> PING 192.168.1.155 56 bytes of data
> 56 bytes from 192.168.1.155: icmp_seq=0 time=38.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=1 time=62.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=2 time=104.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=3 time=124.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=4 time=62.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=5 time=84.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=6 time=12.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=7 time=46.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=8 time=75.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=9 time=106.0 ms
> 10 packets transmitted, 10 received, 0% packet loss, time 10010 ms
> rtt min/avg/max/mdev = 12.000/71.300/124.000/32.655 ms
> nsh> ifconfig
> eth0Link encap:Ethernet HWaddr 52:d3:8e:aa:5d:41 at UP mtu 1486
>  inet addr:192.168.1.251 DRaddr:192.168.1.1 Mask:255.255.255.0
>
> loLink encap:Local Loopback at RUNNING mtu 1518
>  inet addr:127.0.0.1 DRaddr:127.0.0.1 Mask:255.0.0.0
>
>   IPv4   TCP   UDP  ICMP
> Received 000c    0002  000a
> Dropped        
>IPv4VHL:    Frg: 
>Checksum         
>TCP ACK:    SYN: 
>RST:   
>Type         
> Sent 000c    0002  000a
>Rexmit       
>
>
>
> On 2/6/24 16:55, Gregory Nutt wrote:
> > The network monitor is part of apps/netutils/netinit so it is not a
> > part of NSH.  NSH can automatically perform the network initialization
> > if so configured and which, optionally, starts the network monitor
> > thread.  But the logic is not architecturally a part of NSH nor does
> > it depend on N SH.
> >
> > On 2/6/2024 9:32 AM, Nathan Hartman wrote:
> >> On Tue, Feb 6, 2024 at 8:45 AM Sebastien Lorquet 
> >> wrote:
> >>
> >>> However, the default network configuration provided in NuttX
> >>> examples is
> >>> cumbersome and too much linked with NSH
> >>>
> >>> It can work for simple tests and demos, but you will have to write a
> >>> proper network management daemon if you plan to use more than one
> >>> network app.
> >>
> >>
> >> It would be a nice thing if the network management daemon could be
> >> factored
> >> out of NSH so that boards that don't run NSH could have the sa

Re: STM32H7 board with ethernet

[Simon Filgis]

I ordered a new board, to have more time testing at home and to rules out
hw error...

Thank you for the effort!!

Roberto Bucher  schrieb am Fr., 9. Feb.
2024, 19:50:

> Tested on NUCLEO-H743ZI2 board with
>
> ./tools/configure.sh nucleo-h743zi2:pysim
>
> My PC has WIFI and the nucleo board connected to the WIFI box
>
> bucher@debian:~/sviluppo/NUTTX/nuttx$ tio /dev/ttyACM0
> [18:58:30.631] tio v2.7
> [18:58:30.631] Press ctrl-t q to quit
> [18:58:30.631] Connected
> telnetd [5:100]
>
> NuttShell (NSH) NuttX-12.4.0
> nsh> ifconfig
> eth0Link encap:Ethernet HWaddr 52:d3:8e:aa:5d:41 at UP mtu 1486
>  inet addr:192.168.1.251 DRaddr:192.168.1.1 Mask:255.255.255.0
>
> loLink encap:Local Loopback at RUNNING mtu 1518
>  inet addr:127.0.0.1 DRaddr:127.0.0.1 Mask:255.0.0.0
>
>   IPv4   TCP   UDP  ICMP
> Received 0002    0002  
> Dropped        
>IPv4VHL:    Frg: 
>Checksum         
>TCP ACK:    SYN: 
>RST:   
>Type         
> Sent 0002    0002  
>Rexmit       
> nsh> ping 192.168.1.155
> PING 192.168.1.155 56 bytes of data
> 56 bytes from 192.168.1.155: icmp_seq=0 time=89.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=1 time=116.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=2 time=47.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=3 time=82.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=4 time=112.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=5 time=40.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=6 time=77.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=7 time=110.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=8 time=42.0 ms
> 56 bytes from 192.168.1.155: icmp_seq=9 time=74.0 ms
> 10 packets transmitted, 10 received, 0% packet loss, time 10010 ms
> rtt min/avg/max/mdev = 40.000/78.900/116.000/27.332 ms
> nsh>
>
> Best regards
>
> Roberto
>
> On 2/9/24 18:23, Simon Filgis wrote:
> > Dear all,
> >
> > I'm back at the board (NUCLEO-H743ZI2). Using latest master (with
> >
> https://github.com/apache/nuttx/commit/31817335e453eec65e8f5d1163c32efd5da373cb
> )
> > and pysim config is stable.
> >
> > But I am not able to ping. I tried the following setups:
> > PC <-> Nucleo-Board
> > PC <-> Switch <-> Nucleo-Board
> >
> > *Here the output from the board:*
> > nsh> ping 192.168.178.1
> > PING 192.168.178.1 56 bytes of data
> > No response from 192.168.178.1: icmp_seq=0 time=1000 ms
> > No response from 192.168.178.1: icmp_seq=1 time=1000 ms
> > No response from 192.168.178.1: icmp_seq=2 time=1000 ms
> > No response from 192.168.178.1: icmp_seq=3 time=1000 ms
> > No response from 192.168.178.1: icmp_seq=4 time=1000 ms
> > No response from 192.168.178.1: icmp_seq=5 time=1000 ms
> > No response from 192.168.178.1: icmp_seq=6 time=1000 ms
> > No response from 192.168.178.1: icmp_seq=7 time=1000 ms
> > No response from 192.168.178.1: icmp_seq=8 time=1000 ms
> > No response from 192.168.178.1: icmp_seq=9 time=1000 ms
> > 10 packets transmitted, 0 received, 100% packet loss, time 10010 ms
> > nsh> ifconfig
> > eth0Link encap:Ethernet HWaddr 02:55:10:e5:49:a2 at UP mtu 1486
> >  inet addr:192.168.178.5 DRaddr:192.168.178.1 Mask:255.255.255.0
> >
> > lo  Link encap:Local Loopback at RUNNING mtu 1518
> >  inet addr:127.0.0.1 DRaddr:127.0.0.1 Mask:255.0.0.0
> >
> >   IPv4   TCP   UDP  ICMP
> > Received *0020*    001e     *--> there seems to be some
> traffic*
> > Dropped  0002      
> >IPv4VHL:    Frg: 
> >Checksum         
> >TCP ACK:    SYN: 
> >RST:   
> >Type         
> > Sent 000a      000a
> >Rexmit       
> > nsh>
> >
> > *And the output of the PC:*
> > ping 192.168.178.5
> > PING 192.168.178.5 (192.168.178.5) 56(84) bytes of data.
> >  From 192.168.178.1 icmp_seq=1 Destination Host Unreachable
> >  From 192.168.178.1 icmp_seq=2 Destination Host Unreachable
> >
> >   What could it be that I'm doing wrong? Is using DHCP mandatory with
> this
> > config? I set a initial IP adress via menuconfig and I also tried with
> > ifconfig eth0 192
> >
> > Thanks for your help,
> >
> > Simon
> >
> > --
> > Hard- and Softwaredevelopment Consultant
> > Ingenieurbüro-Fil

Re: STM32H7 board with ethernet

[Simon Filgis]

Works like a charm. Thank you!

Simon Filgis  schrieb am Fr., 9. Feb. 2024,
19:58:

> I ordered a new board, to have more time testing at home and to rules out
> hw error...
>
> Thank you for the effort!!
>
> Roberto Bucher  schrieb am Fr., 9. Feb.
> 2024, 19:50:
>
>> Tested on NUCLEO-H743ZI2 board with
>>
>> ./tools/configure.sh nucleo-h743zi2:pysim
>>
>> My PC has WIFI and the nucleo board connected to the WIFI box
>>
>> bucher@debian:~/sviluppo/NUTTX/nuttx$ tio /dev/ttyACM0
>> [18:58:30.631] tio v2.7
>> [18:58:30.631] Press ctrl-t q to quit
>> [18:58:30.631] Connected
>> telnetd [5:100]
>>
>> NuttShell (NSH) NuttX-12.4.0
>> nsh> ifconfig
>> eth0Link encap:Ethernet HWaddr 52:d3:8e:aa:5d:41 at UP mtu 1486
>>  inet addr:192.168.1.251 DRaddr:192.168.1.1 Mask:255.255.255.0
>>
>> loLink encap:Local Loopback at RUNNING mtu 1518
>>  inet addr:127.0.0.1 DRaddr:127.0.0.1 Mask:255.0.0.0
>>
>>   IPv4   TCP   UDP  ICMP
>> Received 0002    0002  
>> Dropped        
>>IPv4VHL:    Frg: 
>>Checksum         
>>TCP ACK:    SYN: 
>>RST:   
>>Type         
>> Sent 0002    0002  
>>Rexmit       
>> nsh> ping 192.168.1.155
>> PING 192.168.1.155 56 bytes of data
>> 56 bytes from 192.168.1.155: icmp_seq=0 time=89.0 ms
>> 56 bytes from 192.168.1.155: icmp_seq=1 time=116.0 ms
>> 56 bytes from 192.168.1.155: icmp_seq=2 time=47.0 ms
>> 56 bytes from 192.168.1.155: icmp_seq=3 time=82.0 ms
>> 56 bytes from 192.168.1.155: icmp_seq=4 time=112.0 ms
>> 56 bytes from 192.168.1.155: icmp_seq=5 time=40.0 ms
>> 56 bytes from 192.168.1.155: icmp_seq=6 time=77.0 ms
>> 56 bytes from 192.168.1.155: icmp_seq=7 time=110.0 ms
>> 56 bytes from 192.168.1.155: icmp_seq=8 time=42.0 ms
>> 56 bytes from 192.168.1.155: icmp_seq=9 time=74.0 ms
>> 10 packets transmitted, 10 received, 0% packet loss, time 10010 ms
>> rtt min/avg/max/mdev = 40.000/78.900/116.000/27.332 ms
>> nsh>
>>
>> Best regards
>>
>> Roberto
>>
>> On 2/9/24 18:23, Simon Filgis wrote:
>> > Dear all,
>> >
>> > I'm back at the board (NUCLEO-H743ZI2). Using latest master (with
>> >
>> https://github.com/apache/nuttx/commit/31817335e453eec65e8f5d1163c32efd5da373cb
>> )
>> > and pysim config is stable.
>> >
>> > But I am not able to ping. I tried the following setups:
>> > PC <-> Nucleo-Board
>> > PC <-> Switch <-> Nucleo-Board
>> >
>> > *Here the output from the board:*
>> > nsh> ping 192.168.178.1
>> > PING 192.168.178.1 56 bytes of data
>> > No response from 192.168.178.1: icmp_seq=0 time=1000 ms
>> > No response from 192.168.178.1: icmp_seq=1 time=1000 ms
>> > No response from 192.168.178.1: icmp_seq=2 time=1000 ms
>> > No response from 192.168.178.1: icmp_seq=3 time=1000 ms
>> > No response from 192.168.178.1: icmp_seq=4 time=1000 ms
>> > No response from 192.168.178.1: icmp_seq=5 time=1000 ms
>> > No response from 192.168.178.1: icmp_seq=6 time=1000 ms
>> > No response from 192.168.178.1: icmp_seq=7 time=1000 ms
>> > No response from 192.168.178.1: icmp_seq=8 time=1000 ms
>> > No response from 192.168.178.1: icmp_seq=9 time=1000 ms
>> > 10 packets transmitted, 0 received, 100% packet loss, time 10010 ms
>> > nsh> ifconfig
>> > eth0Link encap:Ethernet HWaddr 02:55:10:e5:49:a2 at UP mtu 1486
>> >  inet addr:192.168.178.5 DRaddr:192.168.178.1 Mask:255.255.255.0
>> >
>> > lo  Link encap:Local Loopback at RUNNING mtu 1518
>> >  inet addr:127.0.0.1 DRaddr:127.0.0.1 Mask:255.0.0.0
>> >
>> >   IPv4   TCP   UDP  ICMP
>> > Received *0020*    001e     *--> there seems to be some
>> traffic*
>> > Dropped  0002      
>> >IPv4VHL:    Frg: 
>> >Checksum         
>> >TCP ACK:    SYN: 
>> >RST:   
>> >Type         
>> > Sent 000a      000a
>> >Rexmit       
>> > nsh>
>> >
>> > *And the output of the PC:*
>> > ping 192.168.178.5
>> > PING 192.168.178.5 (192.168.178.5) 56(84) bytes of data

Re: mm/mm_heap assertion error

[Simon Filgis]

Is there a way to colorize heap to track down the bandid? Like CRC pattern
on all the spaces around and check on every call that the CRC pattern ist
still OK?

Gregory Nutt  schrieb am Mo., 11. März 2024, 19:27:

> If the memory location that is corrupted is consistent, then you can
> monitor that location to find the culprit (perhaps using debug output).
> If your debugger supports it then setting a watchpoint could also
> trigger a break when the corruption occurs.
>
> Maybe you can also try disabling features until you find the feature
> logic that is corrupting the heap.  There is no easy way to accomplish
> this.
>
> On 3/11/2024 11:27 AM, Nathan Hartman wrote:
> > 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  misc/assert.c:536#1  0x07010248 in __assert
> (filename=0x7060f78 "kasan/kasan.c", linenum=117, msg=0x7060ff0 "panic") at
> assert/lib_assert.c:36
> >>> #2  0x070141d6 in kasan_report (addr=0x708fe90, size=8,
> is_write=false, return_address=0x701aeac  kasan/kasan.c:117
> >>> #3  0x07014412 in kasan_check_report (addr=0x708fe90,
> size=8, is_write=false, return_address=0x701aeac  kasan/kasan.c:190
> >>> #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  misc/assert.c:536#1  0x0700df18 in __assert
> (filename=0x7056060 "mm_heap/mm_malloc.c", linenum=245, msg=0x0) at
> assert/lib_assert.c:36
> >>> #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
> >>> #4  0x0704efd4 in metal_allocate_memory (size=128) at
> .../nuttx/include/metal/system/nuttx/alloc.h:27
> >>> #5  0x0704fd8a in rproc_virtio_create_vdev (role=1,
> notifyid=0,
> >>>     rsc=0x80200050, rsc_io=0x7080408  priv=0x708ecd8,
> >>>     notify=0x704e6d2  rst_cb=0x0)
> >>>     at open-amp/lib/remoteproc/remoteproc_virtio.c:356
> >>> #6  0x0704e956 in remoteproc_create_virtio
> (rproc=0x708ecd8,
> >>>     vdev_id=0, role=1, rst_cb=0x0) at
> open-amp/lib/remoteproc/remoteproc.c:9

Re: Change time_t to signed type

[Simon Filgis]

Thanks. So there are use cases for negative numbers of time. Interesting.


--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>


On Tue, Nov 5, 2024 at 11:03 AM  wrote:

> On 2024-11-05 08:13:19, Simon Filgis wrote:
> > Seems like a dump question, but why time needs to be signed?
> It doesn't. But you may want to go backwards to show date before 1970.
> This is
> usually implemented by using negative time.
>
> --
>
> .-.---.--.-.
> | Michal Lyszczek | Embedded C, Linux |   Company Address|  .-.
> opensource |
> | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|
> supporter |
> | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\
> & |
> | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/)
> programer |
>
> `--^--^--^-'
>

Re: Change time_t to signed type

[Simon Filgis]

Seems like a dump question, but why time needs to be signed?

Guiding Li  schrieb am Di., 5. Nov. 2024, 08:08:

> Hi Greg,
>
> Rather than reducing the size of time_t and joining the systems with the
> year 2038 problem, I think that a better solution is to solve the problem
> permanently.
> ---
> Agree with your last part, we should find a better way to ‘ put things
> right once and for all ’, and not use the unsigned int to *postpone the
> occurrence of things*
>
> So, Someone thinks time_t will overflow when set int32_t, should think
> his code should open TIME64 or handle the overflow himself.
>
>
> Gregory Nutt  于2024年11月5日周二 05:24写道：
>
>> You are right, there is no requirement by any standard that time_t be
>> signed.  Lots of discussion on Wikipedia:
>> https://en.wikipedia.org/wiki/Unix_time
>>
>> The only motivation for making time_t signed is for compatibility with
>> GLIBC.  For example, some very old Unix systems permit negative time values
>> for times before the epoch.  The penalty for this compatibility with a
>> non-standard different is a loss of range and the year 2038 problem.
>>
>> This is the year 2038 problem:
>> https://en.wikipedia.org/wiki/Year_2038_problem
>>
>> Any product released after this change will fail in the field in 2038.
>> That could be an issue for a few systems with very long lives.  Most OSs
>> have already fixed the year 2038 problem... but in different ways.  See the
>> Year_2038_Problem for solutions that are fielded now (one fix, ironically,
>> is to make time_t unsigned).
>>
>> Rather than reducing the size of time_t and joining the systems with the
>> year 2038 problem, I think that a better solution is to solve the problem
>> permanently.
>>
>>
>> On 11/4/2024 2:50 PM, b...@the-wanderers.org wrote:
>>
>> Hi Guiding,
>>
>> Both your reference and the Open Group specification documents both only
>> state that POSIX requires time_t to be an integer type, not a signed
>> integer.
>>
>> The Open Group Base Specifications Issue 8
>> 
>> pubs.opengroup.org 
>> [image: favicon.ico] 
>> 
>>
>> GNU libc additionally mandates a signed integer but notes this is a GNU
>> extension and not a POSIX requirement.
>>
>> The 2024 edition of POSIX has introduced a requirement for time_t to be
>> 64 bits. As has already been noted this is itself a substantial change.
>>
>>   Byron
>>
>> On 4 Nov 2024, at 11:33 PM, Guiding Li 
>>  wrote:
>>
>> Hi all:
>>
>> We decide change 'time_t' from unsigned type to signed type in PR:
>> https://github.com/apache/nuttx/pull/14460
>>
>> Because when compile some POSIX library, there always be a warning on
>> comparison
>> between time_t and zero.
>>
>> For example:
>>
>> The following code will generate warnings:
>> auto now = time(nullptr);
>> auto last_active_time = GetEventService(self->ctx_)->getActiveTime(); if
>> (last_active_time + 60 * 1000 / 1000 <= now) {
>>
>> src/ams/../controller/controller_timer.h: In lambda function:
>> src/ams/../controller/controller_timer.h:117:57: warning: comparison of
>> integer expressions of different signedness: 'long long int' and 'long
>> long
>> unsigned int' [-Wsign-compare]
>> 117 | if (last_active_time + 60 * 1000 / 1000 <= now) {
>>
>>
>> And we can find an reference on the official website:
>>
>> https://www.gnu.org/software/libc/manual/html_node/Time-Types.html
>>
>> On POSIX-conformant systems, time_t is an integer type.
>>
>>
>> The comparation of the merits and shortcomings:
>>
>> Advantage:
>> For the most POSIX applications they assume the time_t as signed and do
>> compare with 0.
>> The code will become more compatible after this modification.
>>
>> Disadvantage:
>> None.
>>
>>
>> If there is any question about this, please let me know.
>> Thanks,
>> Guiding
>>
>>

Re: [Article] LLM Bot that reviews NuttX Pull Requests

[Simon Filgis]

Hi Mr. Lup,

I like!

The LLM should not only check the commenting around the code.

It should also try to review the code.
1. Commented and easy to understand? Simplify naming suggestions.
2. Efficient algorithms? Suggest different implementation, for example
better sorting algorithm.
3. Math errors (brackets, casting, rounding, overflow) prevention.
4. Wrong or missing check of returns detection.
5. I guess many more!

What do you think?

Regards,

Simon


Venkat  schrieb am So., 29. Sept. 2024, 05:28:

> Interesting use case for LLM - Nice. Yes, a 50km hike can make such use
> cases to be thought of!
>
> Venkat
>
> On Sat, Sep 28, 2024 at 3:27 PM Lee, Lup Yuen  wrote:
>
> > We're experimenting with an LLM Bot (Large Language Model) that will
> review
> > NuttX Pull Requests. This article explains how we created the LLM Bot in
> > One Week:
> >
> > (1) We call GitHub API to fetch NuttX Pull Requests
> > (2) Append the PR Body to the NuttX PR Requirements
> > (3) Which becomes the LLM Prompt that we send to Gemini API
> > (4) Our Bot posts the Gemini Response as a PR Review Comment
> > (5) Due to quirks in Gemini API: We use Emoji Reactions to limit the API
> > Calls
> > (6) Though our LLM Bot was created by accident. (It wasn't meant to be an
> > AI Project!)
> >
> > Please check out the article:
> > https://lupyuen.codeberg.page/articles/llm.html
> >
> > Lup
> >
>

Re: New Board / New Chip

[Simon Filgis]

Dear Nathan,

indeed, with switching MCU board-config switches to custom automatically.
It needs to be filled by hand.

Thank you.

Simon

--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>


On Wed, Nov 27, 2024 at 1:55 PM Nathan Hartman 
wrote:

> On Wed, Nov 27, 2024 at 3:42 AM Simon Filgis <
> si...@ingenieurbuero-filgis.de>
> wrote:
>
> > Dear all,
> >
> > I would like to add a board with STM32F030R8. I started with copying
> > STM32F051-DISCOVERY. In menuconfig I can select the correct chip.
> >
> > I need to add defines in nuttx/include/arch/stm32f0l0g0/chip.h
> >
> > Then the build fails with:
> > make[1]: *** No rule to make target '/workspace/nuttx//scripts/flash.ld',
> > needed by '/workspace/nuttx//scripts/flash.ld.tmp'.  Stop.
> > make[1]: *** Waiting for unfinished jobs
> > make: *** [tools/Unix.mk:551: nuttx] Error 2
> >
> > Can someone please give me a tip on how to proceed?
> >
> > Thank you,
> >
> > Simon
>
>
> Hi,
>
> In the make error:
>
> make[1]: *** No rule to make target '/workspace/nuttx//scripts/flash.ld',
>
> Notice where the path has two consecutive // between nuttx and scripts.
> This should be the path to the board directory.
>
> Since it's missing, I think the board hasn't been set in Kconfig, so the
> make variables are being populated with an empty string.
>
> Hope this helps,
> Nathan
>

Re: rcS startup-script

[Simon Filgis]

Dear all,

Everything still works.

There is one thing that I found interesting:
I have a ftp_server running. This server is not accepting long filenames
any more. I cannot remember this limitation from previviouse usage. Though
in the past I saw the file-system of sd card broken and/or filenames cutted
in length ending with "~".

Does anybody have an idea about this?

Regards,

Simon


--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>


On Sat, Nov 16, 2024 at 1:22 PM Simon Filgis 
wrote:

> Hi Xinyong,
>
> with DEFAULT_SMALL enabled it rcS is autostarted again and the open fail
> is gone. So a full solution. Thank you.
>
> But this is changing a lot of my defconfig:
>
> @ -6,9 +6,94 @@
> # modifications.
> #
> # CONFIG_ARCH_LEDS is not set
> +# CONFIG_BINFMT_DISABLE is not set
> +# CONFIG_DISABLE_ENVIRON is not set
> +# CONFIG_DISABLE_MQUEUE is not set
> +# CONFIG_DISABLE_MQUEUE_NOTIFICATION is not set
> +# CONFIG_DISABLE_POSIX_TIMERS is not set
> +# CONFIG_DISABLE_PSEUDOFS_OPERATIONS is not set
> +# CONFIG_DISABLE_PTHREAD is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_BLOCKS is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_CPUINFO is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_ENVIRON is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_IOBINFO is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_MEMDUMP is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_MEMINFO is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_MEMPOOL is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_MOUNT is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_MOUNTS is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_NET is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_PARTITIONS is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_PROCESS is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_TCBINFO is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_UPTIME is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_USAGE is not set
> +# CONFIG_FS_PROCFS_EXCLUDE_VERSION is not set
> +# CONFIG_FS_PROCFS_INCLUDE_PROGMEM is not set
> # CONFIG_IPCFG_WRITABLE is not set
> +# CONFIG_LIBC_STRSIGNAL_SHORT is not set
> # CONFIG_MMCSD_MMCSUPPORT is not set
> # CONFIG_MMCSD_SPI is not set
> +# CONFIG_NSH_DISABLEBG is not set
> +# CONFIG_NSH_DISABLESCRIPT is not set
> +# CONFIG_NSH_DISABLE_ARP is not set
> +# CONFIG_NSH_DISABLE_BASENAME is not set
> +# CONFIG_NSH_DISABLE_CAT is not set
> +# CONFIG_NSH_DISABLE_CD is not set
> +# CONFIG_NSH_DISABLE_CMP is not set
> +# CONFIG_NSH_DISABLE_CP is not set
> +# CONFIG_NSH_DISABLE_DD is not set
> +# CONFIG_NSH_DISABLE_DF is not set
> +# CONFIG_NSH_DISABLE_DIRNAME is not set
> +# CONFIG_NSH_DISABLE_DMESG is not set
> +# CONFIG_NSH_DISABLE_ECHO is not set
> +# CONFIG_NSH_DISABLE_ENV is not set
> +# CONFIG_NSH_DISABLE_ERROR_PRINT is not set
> +# CONFIG_NSH_DISABLE_EXEC is not set
> +# CONFIG_NSH_DISABLE_EXPORT is not set
> +# CONFIG_NSH_DISABLE_EXPR is not set
> +# CONFIG_NSH_DISABLE_FDINFO is not set
> +# CONFIG_NSH_DISABLE_FREE is not set
> +# CONFIG_NSH_DISABLE_GET is not set
> +# CONFIG_NSH_DISABLE_HEXDUMP is not set
> +# CONFIG_NSH_DISABLE_IFCONFIG is not set
> +# CONFIG_NSH_DISABLE_IFUPDOWN is not set
> +# CONFIG_NSH_DISABLE_ITEF is not set
> +# CONFIG_NSH_DISABLE_KILL is not set
> +# CONFIG_NSH_DISABLE_LOOPS is not set
> +# CONFIG_NSH_DISABLE_LOSETUP is not set
> +# CONFIG_NSH_DISABLE_LS is not set
> +# CONFIG_NSH_DISABLE_MKDIR is not set
> +# CONFIG_NSH_DISABLE_MKFATFS is not set
> +# CONFIG_NSH_DISABLE_MKRD is not set
> +# CONFIG_NSH_DISABLE_MOUNT is not set
> +# CONFIG_NSH_DISABLE_MV is not set
> +# CONFIG_NSH_DISABLE_NSLOOKUP is not set
> +# CONFIG_NSH_DISABLE_PIDOF is not set
> +# CONFIG_NSH_DISABLE_PKILL is not set
> +# CONFIG_NSH_DISABLE_PRINTF is not set
> +# CONFIG_NSH_DISABLE_PS is not set
> +# CONFIG_NSH_DISABLE_PSSTACKUSAGE is not set
> +# CONFIG_NSH_DISABLE_PUT is not set
> +# CONFIG_NSH_DISABLE_PWD is not set
> +# CONFIG_NSH_DISABLE_REBOOT is not set
> +# CONFIG_NSH_DISABLE_RM is not set
> +# CONFIG_NSH_DISABLE_RMDIR is not set
> +# CONFIG_NSH_DISABLE_SEMICOLON is not set
> +# CONFIG_NSH_DISABLE_SET is not set
> +# CONFIG_NSH_DISABLE_SLEEP is not set
> +# CONFIG_NSH_DISABLE_SOURCE is not set
> +# CONFIG_NSH_DISABLE_TELNETSTART is not set
> +# CONFIG_NSH_DISABLE_TEST is not set
> +# CONFIG_NSH_DISABLE_TIME is not set
> +# CONFIG_NSH_DISABLE_TRUNCATE is not set
> +# CONFIG_NSH_DISABLE_UMOUNT is not set
> +# CONFIG_NSH_DISABLE_UNAME is not set
> +# CONFIG_NSH_DISABLE_UNSET is not set
> +# CONFIG_NSH_DISABLE_UPTIME is not set
> +# CONFIG_NSH_DISABLE_USLEEP is not set
> +# CONFIG_NSH_DISABLE_WGET is not set
> +# CONFIG_NSH_DISABLE_XD is not set
> # CONFIG_SAMV7_UART2 is not set
> # CONFIG_SAMV7_UART4 is not set
&

New Board / New Chip

[Simon Filgis]

Dear all,

I would like to add a board with STM32F030R8. I started with copying
STM32F051-DISCOVERY. In menuconfig I can select the correct chip.

I need to add defines in nuttx/include/arch/stm32f0l0g0/chip.h

Then the build fails with:
make[1]: *** No rule to make target '/workspace/nuttx//scripts/flash.ld',
needed by '/workspace/nuttx//scripts/flash.ld.tmp'.  Stop.
make[1]: *** Waiting for unfinished jobs
make: *** [tools/Unix.mk:551: nuttx] Error 2

Can someone please give me a tip on how to proceed?

Thank you,

Simon

--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>

rcS startup-script

[Simon Filgis]

Dear all,

I have a board with rcS startup-script and etc/init.d automount.

After updating nuttx it does not work any more.

https://github.com/apache/nuttx/pull/11498
https://github.com/apache/nuttx/pull/11572

Following the guidance in the PR I was able to have my rsS script again
automated. And I can run it from nsh with ". rcS".

But it is not autostarting any more. Before nsh there is the following
output:
"init: open failed: 2"

Does anybody have a thought about this?

Regards,

Simon


--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>

Re: rcS startup-script

[Simon Filgis]

OGMEM=y
CONFIG_NET=y
CONFIG_NETDB_DNSCLIENT=y
+CONFIG_NETDB_DNSCLIENT_ENTRIES=8
CONFIG_NETDEV_PHY_IOCTL=y
CONFIG_NETINIT_DRIPADDR=0xc0a8B201
CONFIG_NETINIT_IPADDR=0xc0a8B232
@@ -99,32 +196,30 @@ CONFIG_NETUTILS_PING=y
CONFIG_NETUTILS_TELNETD=y
CONFIG_NETUTILS_WEBCLIENT=y
CONFIG_NETUTILS_WEBSERVER=y
-CONFIG_NET_ARP_SEND=y
CONFIG_NET_BROADCAST=y
CONFIG_NET_ETH_PKTSIZE=1500
-CONFIG_NET_ICMP=y
CONFIG_NET_ICMP_SOCKET=y
-CONFIG_NET_NACTIVESOCKETS=32
+CONFIG_NET_PREALLOC_DEVIF_CALLBACKS=16
CONFIG_NET_RECV_BUFSIZE=3072
CONFIG_NET_SOLINGER=y
CONFIG_NET_TCP=y
CONFIG_NET_TCPBACKLOG=y
-CONFIG_NET_TCP_CONNS=16
CONFIG_NET_TCP_DELAYED_ACK=y
CONFIG_NET_TCP_WRITE_BUFFERS=y
CONFIG_NET_UDP=y
-CONFIG_NET_UDP_BINDTODEVICE=y
+CONFIG_NSH_ALIAS=y
CONFIG_NSH_ARCHINIT=y
-CONFIG_NSH_ARCHROMFS=y
+CONFIG_NSH_ARGCAT=y
CONFIG_NSH_BUILTIN_APPS=y
-CONFIG_NSH_FILEIOSIZE=512
-CONFIG_NSH_LINELEN=64
-CONFIG_NSH_READLINE=y
-CONFIG_NSH_ROMFSETC=y
+CONFIG_NSH_CMDOPT_HEXDUMP=y
+CONFIG_NSH_QUOTE=y
+CONFIG_NSH_TELNET=y
CONFIG_NSH_TELNET_LOGIN=y
CONFIG_NULLMTD=y
+CONFIG_PID_INITIAL_COUNT=16
CONFIG_PREALLOC_MQ_IRQ_MSGS=32
-CONFIG_PREALLOC_TIMERS=4
+CONFIG_PREALLOC_MQ_MSGS=8
+CONFIG_PTHREAD_MUTEX_ROBUST=y
CONFIG_PWM=y
CONFIG_RAM_SIZE=393216
CONFIG_RAM_START=0x2040
@@ -168,6 +263,7 @@ C

+CONFIG_SIG_PREALLOC_IRQ_ACTIONS=8
CONFIG_SPI_CMDDATA=y
CONFIG_SPI_DELAY_CONTROL=y
CONFIG_STACK_COLORATION=y
@@ -184,10 +280,10 @@ CONFIG_SYSLOG_PROCESS_NAME=y
CONFIG_SYSLOG_TIMESTAMP=y
CONFIG_SYSTEM_CFGDATA=y
CONFIG_SYSTEM_NSH=y
-CONFIG_SYSTEM_RAMTEST=y
CONFIG_SYSTEM_SETLOGMASK=y
CONFIG_SYSTEM_STACKMONITOR=y
CONFIG_SYSTEM_SYSTEM=y
+CONFIG_SYSTEM_TELNETD=y
CONFIG_TIMER=y
CONFIG_UART0_SERIAL_CONSOLE=y
CONFIG_USERLED=y


I start testing.

Best,

Simon

--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>


On Thu, Nov 14, 2024 at 8:55 AM 方新勇  wrote:

> hello,
>
> Did you enable NSH_DISABLESCRIPT option in apps/nshlib/Kconfig, that
> depends on DEFAULT_SMALL as default.
> If DEFAULT_SMALL is disabled, nsh do not autostart rcS startup-script.
>
> But I don't have any idea why output that "init: open failed: 2". Can you
> give me some hints?
>
> Regards,
>
> Xinyong
>
> Simon Filgis  于2024年11月14日周四 15:10写道：
>
> > Dear all,
> >
> > I have a board with rcS startup-script and etc/init.d automount.
> >
> > After updating nuttx it does not work any more.
> >
> > https://github.com/apache/nuttx/pull/11498
> > https://github.com/apache/nuttx/pull/11572
> >
> > Following the guidance in the PR I was able to have my rsS script again
> > automated. And I can run it from nsh with ". rcS".
> >
> > But it is not autostarting any more. Before nsh there is the following
> > output:
> > "init: open failed: 2"
> >
> > Does anybody have a thought about this?
> >
> > Regards,
> >
> > Simon
> >
> >
> > --
> > Hard- and Softwaredevelopment Consultant
> >
> > Geschäftsführung: Simon Filgis
> > USt-IdNr.: DE305343278
> > ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications
> >
> >
>

Re: arm64 zynq-mpsoc was broken

[Simon Filgis]

I would also like to join with:
SAMV7
STM32
ZCU102 (which I would love to run nuttx on - but I need help for that)


--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>


On Tue, Feb 4, 2025 at 9:00 AM zou boan  wrote:

> I am very interested in distributed building and  testing hardware farms,
> and if someone is leading this project, I would be delighted to join.
>
> 获取Outlook for Android<https://aka.ms/AAb9ysg>
> 
> From: Tomek CEDRO 
> Sent: Tuesday, February 4, 2025 2:10:02 AM
> To: dev@nuttx.apache.org 
> Subject: Re: arm64 zynq-mpsoc was broken
>
> Thus the idea for DRUNX (Distributer Runtime and bUild for NuttX) Test
> Environment :-)
>
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
> On Mon, Feb 3, 2025, 14:35 Nathan Hartman 
> wrote:
>
> > I think we should restart the conversation about setting up a build and
> > test farm of real hardware, with a diverse collection of boards and
> > processor architectures. It would be a good thing if we could have BOTH a
> > project-owned centralized farm AND a relatively easy way for individual
> > developers and companies to set up their own.
> >
> > On Mon, Feb 3, 2025 at 7:25 AM raiden00pl  wrote:
> >
> > > I can only guess that this change was verified on QEMU. And here is
> > another
> > > problem that introduces many bugs from Xiaomi: testing changes only on
> > > QEMU.
> > >
> > > This approach has no chance of detecting all bugs and is inherently
> > wrong.
> > > Meaningful tests on QEMU are not possible. Even in cases where
> > > virtualization
> > > is supported by hardware, like for example x86 target on x86 host with
> > KVM.
> > > Problems on real hardware may not be reproducible on QEMU. This also
> > works
> > > in the opposite direction - problems on QEMU that don't occur on HW.
> > >
> > > Fixing such bugs later is a waste of developers' time, especially since
> > > these
> > > bugs are really hard to find.
> > >
> > > pon., 3 lut 2025 o 12:32 zou boan  napisał(a):
> > >
> > > > The latest progress:
> > > >
> > > >After a day of troubleshooting, I have confirmed that the
> issue
> > > was
> > > > caused by stack misalignment. The pull request #15437 changes
> > > > ARM64_CONTEXT_REGS from 36 to 37, resulting in the stack no longer
> > being
> > > > 16-byte aligned, when i changes ARM64_CONTEXT_REGS from 37 to 38, the
> > > > ZCU111 board is alive. I have submitted a PR(#15748) to fix this
> issue,
> > > and
> > > > I would appreciate anyone to provide better suggestions.
> > > >
> > > > Thank you very much!
> > > >
> > > >
> > > > 
> > > > 发件人: zou boan 
> > > > 发送时间: 2025年2月3日 15:50
> > > > 收件人: dev@nuttx.apache.org 
> > > > 主题: arm64 zynq-mpsoc was broken
> > > >
> > > > Hi:
> > > >
> > > >   Today, I pulled and synchronized the latest NuttX, but after
> > > > successfully compiling it, I found that it failed to run. Through the
> > > > process of bisecting, the issue was ultimately pinpointed to Pull
> > Request
> > > > #15437 https://github.com/apache/nuttx/pull/15437
> > > >   The pull request #15437 lacks test logs, leaving me uncertain
> as
> > to
> > > > whether it has been validated through real hardware testing. These
> are
> > > the
> > > > outcomes of my tests on the ZCU111 board regarding the jtag and nsh
> > > > configurations.  The pull request #15437 changes ARM64_CONTEXT_REGS
> > from
> > > 36
> > > > to 37, resulting in the stack no longer being 16-byte aligned, which
> > > > appears to violate the ARMv8-A architecture's requirement for 16-byte
> > > stack
> > > > alignment. While I encountered this issue on the ZCU111 hardware, I
> am
> > > > unsure whether other ARM64 hardware platforms might be similarly
> > > affected.
> > > > If anyone has experience or insights regarding other ARM64 hardware,
> > > could
> > > > you share your advice? Specifically, I would appreciate details on
> how
> > > > stack alignment requirements are implemented or any potential
> > workarounds
> &g

Re: [DRUNX] Distributed Runtime and bUild for NuttX

[Simon Filgis]

Dear all,

each arch, driver and app tested once would be enough I think. A matrix can
help to identify test-gaps. Double testing is nice and triple testing is
not of benefit any more.

The goal should be to have fast access to results with transparency. I fear
starting to maintain a useless monster ;)

Simon

--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>


On Wed, Feb 5, 2025 at 1:27 PM Alan C. Assis  wrote:

> I think we should test the most complete/complex boards from each arch. It
> will cover most of the issues that could after other boards.
>
> BR,
>
> Alan
>
> On Wed, Feb 5, 2025 at 4:23 AM raiden00pl  wrote:
>
> > As mentioned earlier, testing all boards is pointless, especially since
> the
> > project
> > has very limited resources. Choosing a few boards that will allow us to
> > test as many
> > things as possible is the most optimal approach.
> >
> > But first we should determine what things we want to test, not what
> boards.
> > Knowing what things we want to test, we can design test cases and
> possibly
> > use what is already available.
> >
> > But e-mail and github don't seem to me to be a good tool for
> brainstorming
> > and ideas. Maybe Confluence pages would be better? I haven't used
> > Confluence
> > for a few years, I just hope it's not as slow as it used to be :)
> >
> > I can create a Confluence page and describe my ideas about testing, I
> have
> > some
> > thoughts about NuttX testing written somewhere in my private notes.
> Others
> > can do
> > the same.
> >
> > Email can be good for decision making and maybe gathering more feedback
> > from
> > the community, but it's a shitty tool for more complex work. Or I'm too
> > young
> > to use it comfortably :P
> >
> > wt., 4 lut 2025 o 12:03 Tomek CEDRO  napisał(a):
> >
> > > On Tue, Feb 4, 2025 at 11:42 AM Luchian Mihai <
> luchiann.mi...@gmail.com>
> > > wrote:
> > > > Hi!
> > > > First thing, I'm fairly new to nuttx so I might be off subject but
> here
> > > is
> > > > my hot take on this subject.
> > >
> > > Welcome and have fun Mihai! :-)
> > >
> > >
> > > > NuttX is offering support for a lot of boards, more than what DRUNX
> > > should
> > > > require.
> > > >
> > > > Eg. stm32f3 family, offering support for all the boards would benefit
> > the
> > > > boards more than the NuttX codebase.
> > > > These boards share 80% of the code but each in its own files, so most
> > > > differences are due to lack of backporting.
> > > >
> > > > My suggestion is to take a single board for each mcu family as
> > mandatory
> > > > NuttX support, others as optional.
> > > > I'm not saying to drop support, or offer less support for those, just
> > to
> > > > treat the mandatory as higher prio.
> > > > For the moment we can choose what is mandatory, and at a later time,
> > when
> > > > DRUNX would be stable, move the optional ones to DRUNX repo (for
> > > example).
> > >
> > > The idea is that everyone can test what they have at hand and then
> > > gather the results, that should sum up to full board list one day :-)
> > > Also different people will use different build hosts, different
> > > compilers, etc, so even if the same board is tested in different build
> > > environment that can also reveal potential issues to be fixed :-)
> > >
> > > Yes, for sure we need at least one board from each family for start,
> > > then adding more boards, we all do release testing that way or
> > > another, by hand or scripted, we now have to find a way to make it
> > > distributed easy to setup fire-and-forget :-)
> > >
> > >
> > > > TLDR: I think less is more, less "official" support, more "official"
> > > > coverage.
> > >
> > > More means more. Less means less. Lets keep thing simple in this
> > > inverted world where word have no meaning anymore :D :D :D
> > >
> > > Its a small project based on voluntary work with zero financial
> > > support from big companies. We will define a testing architecture for
> > > sure, but for now its a fresh concept and each one of us try different
> > > area to create s

Re: [DRUNX] Distributed Runtime and bUild for NuttX

[Simon Filgis]

or starting to implement a monster that only prevents anyone from changing.
"No change anymore" can be implemented easier, just stop working and go on
vacation, haha. But no joke, that's also a way to send a project to death.

--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>


On Wed, Feb 5, 2025 at 2:39 PM Simon Filgis 
wrote:

> Dear all,
>
> each arch, driver and app tested once would be enough I think. A matrix
> can help to identify test-gaps. Double testing is nice and triple testing
> is not of benefit any more.
>
> The goal should be to have fast access to results with transparency. I
> fear starting to maintain a useless monster ;)
>
> Simon
>
> --
> Hard- and Softwaredevelopment Consultant
>
> Geschäftsführung: Simon Filgis
> USt-IdNr.: DE305343278
> ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>
>
>
> On Wed, Feb 5, 2025 at 1:27 PM Alan C. Assis  wrote:
>
>> I think we should test the most complete/complex boards from each arch. It
>> will cover most of the issues that could after other boards.
>>
>> BR,
>>
>> Alan
>>
>> On Wed, Feb 5, 2025 at 4:23 AM raiden00pl  wrote:
>>
>> > As mentioned earlier, testing all boards is pointless, especially since
>> the
>> > project
>> > has very limited resources. Choosing a few boards that will allow us to
>> > test as many
>> > things as possible is the most optimal approach.
>> >
>> > But first we should determine what things we want to test, not what
>> boards.
>> > Knowing what things we want to test, we can design test cases and
>> possibly
>> > use what is already available.
>> >
>> > But e-mail and github don't seem to me to be a good tool for
>> brainstorming
>> > and ideas. Maybe Confluence pages would be better? I haven't used
>> > Confluence
>> > for a few years, I just hope it's not as slow as it used to be :)
>> >
>> > I can create a Confluence page and describe my ideas about testing, I
>> have
>> > some
>> > thoughts about NuttX testing written somewhere in my private notes.
>> Others
>> > can do
>> > the same.
>> >
>> > Email can be good for decision making and maybe gathering more feedback
>> > from
>> > the community, but it's a shitty tool for more complex work. Or I'm too
>> > young
>> > to use it comfortably :P
>> >
>> > wt., 4 lut 2025 o 12:03 Tomek CEDRO  napisał(a):
>> >
>> > > On Tue, Feb 4, 2025 at 11:42 AM Luchian Mihai <
>> luchiann.mi...@gmail.com>
>> > > wrote:
>> > > > Hi!
>> > > > First thing, I'm fairly new to nuttx so I might be off subject but
>> here
>> > > is
>> > > > my hot take on this subject.
>> > >
>> > > Welcome and have fun Mihai! :-)
>> > >
>> > >
>> > > > NuttX is offering support for a lot of boards, more than what DRUNX
>> > > should
>> > > > require.
>> > > >
>> > > > Eg. stm32f3 family, offering support for all the boards would
>> benefit
>> > the
>> > > > boards more than the NuttX codebase.
>> > > > These boards share 80% of the code but each in its own files, so
>> most
>> > > > differences are due to lack of backporting.
>> > > >
>> > > > My suggestion is to take a single board for each mcu family as
>> > mandatory
>> > > > NuttX support, others as optional.
>> > > > I'm not saying to drop support, or offer less support for those,
>> just
>> > to
>> > > > treat the mandatory as higher prio.
>> > > > For the moment we can choose what is mandatory, and at a later time,
>> > when
>> > > > DRUNX would be stable, move the optional ones to DRUNX repo (for
>> > > example).
>> > >
>> > > The idea is that everyone can test what they have at hand and then
>> > > gather the results, that should sum up to full board list one day :-)
>> > > Also different people will use different build hosts, different
>> > > compilers, etc, so even if the same board is tested in different build
>> > > environment that can also reveal potential issues to be fixed :-)
>> > >
>> > > Yes, for s

Re: trust in nuttx gone

[Simon Filgis]

Hi Alin,

thank you. Very fine for me!

Regards,

Simon

Alin Jerpelea  schrieb am Mi., 29. Jan. 2025, 12:48:

> Hi Simon,
>
> you can always vote as a community member with -1 and explain what the
> issue is (you can check the last release vote thread)
>
> The release process for each release:
> 1) a release branch created 3-4 weeks before the release. (you can test
> your board on it and post bugs in the bug report)
> 2) the release manager will back-port fixes to the branch and make sure
> that the release branch is in good shape (no new features will be added)
> 3) the release manager will create the RC releases and submit them for
> community vote
> 4) the community will test the RC and vote the release
> - if the issue is affecting just a board will not stop the release (we will
> document it as a known issue with the release
> - if the issue if affecting multiple boards or platforms we will stop the
> release, get back to step 2
> 5) if the release passes the community vote it becomes official
>
> NuttX tries to stick to a quarterly release (release branches will appear
> in March, June, September, December with releases aimed for the end of each
> of those months depending depending on voting results).
>
> I hope that this process answers your questions
>
> Best regards
> Alin
>
>
>
> On Wed, Jan 29, 2025 at 12:30 PM Simon Filgis <
> si...@ingenieurbuero-filgis.de> wrote:
>
> > Just for my understanding, could I vote -1 for a release that is not
> > building/working properly for my board?
> >
> > Alin Jerpelea  schrieb am Mi., 29. Jan. 2025, 12:24:
> >
> > > Hi all,
> > >
> > > I started a thread some time ago asking for imput and wishes from all
> of
> > us
> > > so that we cans set some goals and create a roadmap
> > > Unfortunately the mail got little tractionmaybe now we can revive
> it
> > > and complete a roadmap
> > >
> > > Best regards
> > > Alin
> > >
> > > On Wed, 29 Jan 2025, 12:14 raiden00pl,  wrote:
> > >
> > > > I completely agree that project management in NuttX is either lacking
> > or
> > > > completely non-existent. I think the lack of a generally accepted
> road
> > > map
> > > > for
> > > > the project is the biggest problem here. TBH we don't even know where
> > > > the project is headed. Probably if this large number of commits were
> > > > supported
> > > > by some kind of roadmap so that it would be known what the goal of
> > these
> > > > changes is - it would make more sense.
> > > >
> > > > In the long run, without coordinated collaboration between teams
> > working
> > > > separately on NuttX and without a commonly accepted roadmap, I think
> > the
> > > > project
> > > > may fail spectacularly.
> > > >
> > > > This is where the advantage of BDFL projects comes in. One person has
> > > > authority over the project and manages it according to his/her
> vision.
> > > > Managing a project in a distributed manner is a difficult task,
> > > > and so far we are not succeeding at it. I think NuttX hasn't
> correctly
> > > > transitioned from being managed by Greg (BDFL model) to being managed
> > by
> > > > distributed management yet. And this is the biggest problem here.
> > > >
> > > > And how to fix it? I have no idea, but I don't think limiting the
> > number
> > > of
> > > > changes
> > > > to the project is a solution. Maybe a good first step is to discuss
> and
> > > > establish
> > > > a project roadmap with its contributors and companies that are
> > interested
> > > > in it.
> > > > But this requires someone to coordinate the process and preferably
> has
> > > > experience
> > > > in managing distributed open source projects. I don't know if we have
> > > such
> > > > a person in our group.
> > > >
> > > > śr., 29 sty 2025 o 11:33 Sebastien Lorquet 
> > > > napisał(a):
> > > >
> > > > > hi
> > > > >
> > > > >
> > > > > On 29/01/2025 10:21, raiden00pl wrote:
> > > > > > Sebastian, so you're saying that you and your company have the
> > > > resources
> > > > > to
> > > > > > develop
> > > > > > and maintain your own RTOS, but you lack the resources to hel

Re: trust in nuttx gone

[Simon Filgis]

Just for my understanding, could I vote -1 for a release that is not
building/working properly for my board?

Alin Jerpelea  schrieb am Mi., 29. Jan. 2025, 12:24:

> Hi all,
>
> I started a thread some time ago asking for imput and wishes from all of us
> so that we cans set some goals and create a roadmap
> Unfortunately the mail got little tractionmaybe now we can revive it
> and complete a roadmap
>
> Best regards
> Alin
>
> On Wed, 29 Jan 2025, 12:14 raiden00pl,  wrote:
>
> > I completely agree that project management in NuttX is either lacking or
> > completely non-existent. I think the lack of a generally accepted road
> map
> > for
> > the project is the biggest problem here. TBH we don't even know where
> > the project is headed. Probably if this large number of commits were
> > supported
> > by some kind of roadmap so that it would be known what the goal of these
> > changes is - it would make more sense.
> >
> > In the long run, without coordinated collaboration between teams working
> > separately on NuttX and without a commonly accepted roadmap, I think the
> > project
> > may fail spectacularly.
> >
> > This is where the advantage of BDFL projects comes in. One person has
> > authority over the project and manages it according to his/her vision.
> > Managing a project in a distributed manner is a difficult task,
> > and so far we are not succeeding at it. I think NuttX hasn't correctly
> > transitioned from being managed by Greg (BDFL model) to being managed by
> > distributed management yet. And this is the biggest problem here.
> >
> > And how to fix it? I have no idea, but I don't think limiting the number
> of
> > changes
> > to the project is a solution. Maybe a good first step is to discuss and
> > establish
> > a project roadmap with its contributors and companies that are interested
> > in it.
> > But this requires someone to coordinate the process and preferably has
> > experience
> > in managing distributed open source projects. I don't know if we have
> such
> > a person in our group.
> >
> > śr., 29 sty 2025 o 11:33 Sebastien Lorquet 
> > napisał(a):
> >
> > > hi
> > >
> > >
> > > On 29/01/2025 10:21, raiden00pl wrote:
> > > > Sebastian, so you're saying that you and your company have the
> > resources
> > > to
> > > > develop
> > > > and maintain your own RTOS, but you lack the resources to help
> maintain
> > > > NuttX (e.g., code review, release testing.)?
> > > > This either doesn't make sense or you just don't want to participate
> in
> > > > this project.
> > >
> > > I dont have resources for a project as large as nuttx, obviously. And I
> > > dont need to.
> > >
> > > it will take some time and it will be much simpler. In fact I have a
> > > project that is almost working for this including a vfs.
> > >
> > > Or I'll find a project that cares about long term support.
> > >
> > >
> > > But for sure, I'll get rid of nuttx, thats enough: every time I update,
> > > everything is broken, the build system is not stable, and what used to
> > > work does not work anymore, including things as simple as the
> > > configure.sh script. it takes ages just to get our code to compile
> again
> > > before I can consider any improvement.
> > >
> > > I dont have energy to spend for such dumb fixes. I'm loosing my time in
> > > a completely useless way.
> > >
> > > I prefer sending more time being productive with the goal of
> controlling
> > > our software stack.
> > >
> > >
> > > > Cherry-picking a single commit to justify your frustration isn’t
> fair.
> > > > Yes, some commits may be poorly described, but we actively try to
> > > improve in
> > > > that regard. With a limited number of contributors, it’s
> understandable
> > > > that our
> > > > reviews aren’t perfect. However, it's worth noting that neither you
> nor
> > > > your company contributed to addressing this issue.
> > >
> > > come on, do you really think it's just one commit? if you cant guess,
> no
> > > it isnt. this was just an example to show that your own policies are
> not
> > > even applied correctly.
> > >
> > > before using ai to review pull requests, just make sure that commit
> > > messages are useful! But you cant, there's too many stuff to check.
> > > that's a huge red flag for me.
> > >
> > > it's an accumulation of problems, for years, with no changes, and it's
> > > getting worse. The more you add auto tool, the more they are
> > > circumvented, because developers know that no one will check.
> > >
> > >
> > > No, I dont want to fix anything in nuttx anymore. it's no use. I'm a
> > > drop in an ocean, just complaining to a community that does not care
> and
> > > just want to code faster than light.
> > >
> > > also, you have several developers pushing hundreds of commit every
> week.
> > > if they wanted to fix anything, they would do it.
> > >
> > >
> > > >
> > > > That’s completely fine, everyone has different priorities. What is
> NOT
> > > OK is
> > > > criticizing those who dedicate their time to this

Re: STM32F479NGH6 + Ethernet

[Simon Filgis]

Seems like


   1. DP83848C
   There is some code for it in stm32_x.c  and it is placed on an old
   evaluation board of STM: STM32469I-EVAL
   And another board, that is already in nuttx boards:
   
https://www.viewtool.com/index.php/en/36-2016-09-26-03-58-56/99-ficus-stm32f107
   Not sure where to by the second board and how good support is.
   2. KSZ90x1
   There seems to be code for it in stm32_x.c and I have it running in two
   SAMV7 projects. But there is no board in the tree for usage or I don't find
   it.
   3. KSZ8081
   There is some code for it in stm32_x.c  and it is placed on an old
   evaluation board: linum-stm32h753bi
   Cant find a vendor for the board
   4. KSZ8061
   There seems to be code for it in stm32_x.c and I have it running in two
   SAMV7 projects. But there is no board in the tree for usage with STM32.
   5. KSZ8051
   There seems to be code for it in stm32_x.c and I have it running in two
   SAMV7 projects. But there is no board in the tree for usage with STM32.



   - So KSZ8061 has a good change and I know it performs well in Nuttx
   with SAMv7, but
   - DP83848C has a old board in tree very near to the target processor:
   STM32469I - while I will have to use STM32F479NG.


Are there any suggestions on how to decide between those two?
Did I miss an option?


Best Regards,


Simon


--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>


On Sun, Jun 8, 2025 at 6:06 PM Simon Filgis 
wrote:

> Dear all,
>
> I want to add ethernet to a new project based on STM32F479NGH6.
>
> Has somebody worked with this configuration? Any tips or recommendations
> in choosing a MAC phy?
>
> I would like to have a proof of concept (switch to nuttx) with very little
> effort.
>
> Best regards,
>
> Simon
>
> --
> Hard- and Softwaredevelopment Consultant
>
> Geschäftsführung: Simon Filgis
> USt-IdNr.: DE305343278
> ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>
>

Re: [OT] NuttX Standard Board

[Simon Filgis]

Hi Alan,

What about copying known standards. Like Phytec SOM, Toradex, Kontron. That
would attract market shares.

Need to fill your list with my boards and start testing. It's in the
backlog for too long.

Simon

--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>

Alan C. Assis  schrieb am Di., 10. Juni 2025, 23:51:

> Hi Simon,
>
> The idea is not to limit users choice, but have standard connector with
> known pinouts to test different microcontrollers.
>
> For people who develop tailored hardware it will be very useful because you
> can develop an internal baseboard to test some ideas and just exchance the
> MCU module to see how things work in a different chip architecture.
>
> We will not have a just a single baseboard, even because it is impossible
> to have a single board and test all the drivers of NuttX.
>
> But we can start with some basic peripherals to do basic hardware testings
> and avoid regression.
>
> BR,
>
> Alan
>
> Em ter., 10 de jun. de 2025, 17:02, Simon Filgis
>  escreveu:
>
> > I don't like the term standard hardware. Maybe because I create tailored
> > hardware for a living.
> >
> > I love Nuttx for the flexibility.
> >
> > Please do not limit choice of hardware.
> >
> > --
> > Hard- and Softwaredevelopment Consultant
> >
> > Geschäftsführung: Simon Filgis
> > USt-IdNr.: DE305343278
> > ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications
> >
> >
> > Nathan Hartman  schrieb am Di., 10. Juni 2025,
> > 21:07:
> >
> > > Hi all,
> > >
> > > I have a few suggestions::
> > >
> > > 1. I suggest to request INFRA to create a new repository for the design
> > and
> > > implementation of hardware, which initially will contain the NuttX
> > Standard
> > > Board hardware. I suggest the name nuttx-hardware.
> > >
> > > 2. Within the nuttx-hardware repository, I suggest to have a
> subdirectory
> > > for the main board, and subdirectories for each MCU board that can plug
> > in.
> > > In the future, we might add other boards within the same repository.
> > >
> > > 3. I strongly recommend to use a free/open source electronics design
> > > package. (The only one I am familiar with is KiCad [1].) By using
> > free/open
> > > source software, anyone will be able to participate without having to
> pay
> > > expensive licensing costs for a commercial electronics design software.
> > >
> > > Thanks to everyone for your efforts!
> > >
> > > Nathan
> > >
> > > On Tue, Jun 10, 2025 at 1:51 PM Alan C. Assis 
> wrote:
> > >
> > > > Hi Tomek,
> > > >
> > > > Thank you for those nice suggestions.
> > > >
> > > > 1) Yes, even some companies like Freescale (now NXP) used that idea
> in
> > > the
> > > > past, i.e. DEMOQE board:
> > > > https://www.nxp.com/docs/en/user-guide/DEMOQE128UM.pdf
> > > > The MCU module boards need to have a minimum size to fit the
> connector
> > > and
> > > > also we need to think that some MCUs have a "big" package like
> LQFP176
> > > for
> > > > example.
> > > > In this case we are going to use 2 100-pin connectors, the same used
> on
> > > > Raspberry Pi CM4. This connector is low cost and has many pins.
> > > >
> > > > 2) Yes, this is something we should have in the board to support
> > sensors,
> > > > modem, etc. mikroBUS and Pmod will be used, but we can think about
> > using
> > > > others as well.
> > > >
> > > > 3) The baseboard will have a USB/Serial interface to connect in the
> > > > computer, at the moment we didn't know about include a programmer on
> it
> > > to
> > > > avoid increasing boards, the idea is just using JTAG/SWD/ISP
> > connectors.
> > > > Remember that this baseboard will be used not only for ARM, but also
> > > > RISC-V, AVR, etc.
> > > >
> > > > 4) The connector will be unique for all MCU modules, but we will have
> > two
> > > > connectors: the first one is Required and will have all signals
> common
> > > > between almost all MCUs (UART, SPI, I2C, GPIO, etc), the second will
> be
> > > > Optional and will include signal present on more "advanced" MCUs:
> >

STM32F479NGH6 + Ethernet

[Simon Filgis]

Dear all,

I want to add ethernet to a new project based on STM32F479NGH6.

Has somebody worked with this configuration? Any tips or recommendations in
choosing a MAC phy?

I would like to have a proof of concept (switch to nuttx) with very little
effort.

Best regards,

Simon

--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>

Re: [OT] NuttX Standard Board

[Simon Filgis]

I don't like the term standard hardware. Maybe because I create tailored
hardware for a living.

I love Nuttx for the flexibility.

Please do not limit choice of hardware.

--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>

Nathan Hartman  schrieb am Di., 10. Juni 2025,
21:07:

> Hi all,
>
> I have a few suggestions::
>
> 1. I suggest to request INFRA to create a new repository for the design and
> implementation of hardware, which initially will contain the NuttX Standard
> Board hardware. I suggest the name nuttx-hardware.
>
> 2. Within the nuttx-hardware repository, I suggest to have a subdirectory
> for the main board, and subdirectories for each MCU board that can plug in.
> In the future, we might add other boards within the same repository.
>
> 3. I strongly recommend to use a free/open source electronics design
> package. (The only one I am familiar with is KiCad [1].) By using free/open
> source software, anyone will be able to participate without having to pay
> expensive licensing costs for a commercial electronics design software.
>
> Thanks to everyone for your efforts!
>
> Nathan
>
> On Tue, Jun 10, 2025 at 1:51 PM Alan C. Assis  wrote:
>
> > Hi Tomek,
> >
> > Thank you for those nice suggestions.
> >
> > 1) Yes, even some companies like Freescale (now NXP) used that idea in
> the
> > past, i.e. DEMOQE board:
> > https://www.nxp.com/docs/en/user-guide/DEMOQE128UM.pdf
> > The MCU module boards need to have a minimum size to fit the connector
> and
> > also we need to think that some MCUs have a "big" package like LQFP176
> for
> > example.
> > In this case we are going to use 2 100-pin connectors, the same used on
> > Raspberry Pi CM4. This connector is low cost and has many pins.
> >
> > 2) Yes, this is something we should have in the board to support sensors,
> > modem, etc. mikroBUS and Pmod will be used, but we can think about using
> > others as well.
> >
> > 3) The baseboard will have a USB/Serial interface to connect in the
> > computer, at the moment we didn't know about include a programmer on it
> to
> > avoid increasing boards, the idea is just using JTAG/SWD/ISP connectors.
> > Remember that this baseboard will be used not only for ARM, but also
> > RISC-V, AVR, etc.
> >
> > 4) The connector will be unique for all MCU modules, but we will have two
> > connectors: the first one is Required and will have all signals common
> > between almost all MCUs (UART, SPI, I2C, GPIO, etc), the second will be
> > Optional and will include signal present on more "advanced" MCUs:
> Ethernet,
> > Parallel LCD, USB, I2S Audio, etc.
> >
> > I moved the project to: https://github.com/NuttX/nuttx_board_std but I
> > don't know if all people will see it or only those that are part of the
> > organization.
> >
> > BR,
> >
> > Alan
> >
> > On Tue, Jun 10, 2025 at 12:26 PM Tomek CEDRO  wrote:
> >
> > > Aaah! NuttX BaseBoard is more self-exlpanatory thanks Alan! :-)
> > >
> > > I played like this in the 1990's with 8051 but instead having one
> > > single board I created separate modules that were attached with 2.54
> > > wires and f/m-connectors this allowed me to reuse different modules
> > > with different boards and applications. This is now called Arduino
> > > served with modules on breadboards :-P
> > >
> > > I have many MCU boards on a wall of medium size breadboards (SYB-118)
> > > connected over 16 port USB HUBs, some observations below that may give
> > > some hints on the BaseBoard:
> > >
> > > 1. Some boards are bigger and takes unnecessary space for just MCU
> > > testing, so tiny MCU boards are the best (like XIAO series). Several
> > > small MCU boards can fit on a single breadboard, while big boards
> > > (i.e. STM) needs to use two breadboards. Small increase in size of a
> > > breadboard is big increase in price, so I bought 100x SYB-118 as the
> > > compromise between size and price (these also have mounting holes).
> > >
> > > 2. We may want to have slots for different peripherals (i.e. several
> > > stdandars I2C slots for sensor boards). Peripherals switching is
> > > problematic and in perfect situation with my current environment I
> > > would like to be able remotely re-route MCU board to a specific
> > > peripheral that would allow testing. I know this is extremely
> > > problemati

Re: Follows the Conventional Commits //was: Avoid including "[BREAKING]" in the commit title

[Simon Filgis]

Why do we need braking changes.

The only argument I read is: same function name, but not same function.

Anything else?

--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>

Tomek CEDRO  schrieb am Mo., 11. Aug. 2025, 18:55:

>
> https://www.conventionalcommits.org/en/v1.0.0/#commit-message-with-both--and-breaking-change-footer
> says:
>
> """
> Commit message with both ! and BREAKING CHANGE footer
>
> chore!: drop support for Node 6
>
> BREAKING CHANGE: use JavaScript features not available in Node 6.
> """
>
> + we also require "Signed-off-by:" commit footer which is not part of
> the Conventional Commits standard :-P
>
> I like Alin's idea best to put "!" as first character in git commit
> and PR title this is the simplest possible marking no matter what goes
> after and its easiest to parse :-) Maybe we should update Conventional
> Commits? :D
>
> Thanks :-)
> Tomek
>
>
>
>
>
>
> On Mon, Aug 11, 2025 at 1:59 PM Alan C. Assis  wrote:
> >
> > Hi Tomek,
> >
> > Yes, I agree! We could require "!" in the title and "BREAKING CHANGE: "
> in
> > the git commit message.
> >
> > Although the conventional commits spec suggest one or other I think it
> > makes sense to have both to make things clear.
> >
> > BR,
> >
> > Alan
> >
> > On Sun, Aug 10, 2025 at 7:30 PM Tomek CEDRO  wrote:
> >
> > > The real problem here is that breaking changes were passed unmarked :-(
> > >
> > > We can change marking no problem, but we need some sort of mark both
> > > in git commit topic and PR title, do you agree Alan?
> > >
> > > Tomek
> > >
> > > On Sun, Aug 10, 2025 at 3:50 PM Alan C. Assis 
> wrote:
> > > >
> > > > Hi Tomek,
> > > >
> > > > It is not hiding the breaking change, it just avoids using it in the
> > > commit
> > > > title for the reasons I explained before.
> > > >
> > > > It is better to follow what other open-source projects do (like Linux
> > > > kernel, Zephyr, etc) instead of creating something that is unique to
> our
> > > > project and that could confuse users.
> > > >
> > > > If there is a standardized way to define "BREAKING CHANGE: " let's
> follow
> > > > it.
> > > >
> > > > I think there is a good reason why nobody is using "[BREAKING]" in
> the
> > > git
> > > > commit title these three months.
> > > > So, let's avoid adding it to the commit title, let's follow
> > > > the conventional commits!
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Sat, Aug 9, 2025 at 6:45 PM Tomek CEDRO  wrote:
> > > >
> > > > > On Sat, Aug 9, 2025 at 11:10 PM Tomek CEDRO 
> wrote:
> > > > > >
> > > > > > On Sat, Aug 9, 2025 at 9:47 PM Alan C. Assis 
> > > wrote:
> > > > > > >
> > > > > > > Hi Everyone,
> > > > > > >
> > > > > > > I'm proposing to modify the item 1.13.9 from our
> CONTRIBUTING.md to
> > > > > avoid
> > > > > > > including the prefix "[BREAKING]" in the commit title for the
> > > following
> > > > > > > reasons:
> > > > > > >
> > > > > > > * It passes a wrong message, as something very negative (not
> all
> > > > > > > breaking are bad, or shouldn't be)
> > > > > > > * Someone reading our git history could get a wrong impression
> of
> > > the
> > > > > > > project
> > > > > > > * It will cluttering the title, by convention the title should
> have
> > > > > only 50
> > > > > > > chars
> > > > > > > * It doesn't follow the conventional commits specification:
> > > > > > > https://www.conventionalcommits.org/en/v1.0.0/
> > > > > > >
> > > > > > > So, please verify the suggested modification here:
> > > > > > > https://github.com/apache/nuttx/pull/16823
> > > > > > >
> > > > > > > The suggestion as defined by conventional commits is to
> include