Re: [OT] We got 2 projects approved to GSoC 2025
Thank you all for the warm welcome. I am very much looking forward to the journey with NuttX. Currently, I must focus on finishing my bachelor degree. From the second part of June though, the full-time NuttX development begins. Wishes, michal P.S.: Just dropped a little PR https://github.com/apache/nuttx/pull/16392 > On 10. 5. 2025, at 0:05, Tomek CEDRO wrote: > > CONGRATZ! AND HAVE FUN FOLKS :-) :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > >> On Fri, May 9, 2025, 13:45 Alan C. Assis wrote: >> >> Dear NuttXers, >> >> Great news! NuttX was again accepted to GSoC! >> >> These are the projects and contributors: >> >> NuttX Support for IEEE 802.3-2022 10BASE-T1x Ethernet using Open Alliance >> SPI MAC-PHYs >> Michal Matias >> >> Firmware Upgrades over Silicon-Heaven Protocol for NXboot Demonstrated on >> pysimCoder >> Štěpán Pressl >> >> In total 27 projects from Apache Foundation were accepted. >> >> Congratulations and welcome contributors. >> >> BR, >> >> Alan >>
Re: [nuttx] nuttx.org going away
On 2020-08-30 10:36:25, patacongo wrote: > > For many years, the NuttX website was at nuttx.org. However, when NuttX > joined the Apache Software Foundation (ASF) as an incubating project, the > website was redesigned and is now at nuttx.apache.org. The nuttx.org > currently just redirects to nuttx.apache.org. > > I will be ending that re-direction primarily do to certificate issues that > are just not worth bothering with. So within the next 24 hours, nuttx.org > will no longer take you to the nuttx.apache.org website. Please update > your links. Wouldn't it be better to at least simply write "project moved to nuttx.apache.org" and maybe some usefull links like wiki, mailing list, git repo etc? Right now someone might think project is dead or something if one visits that site from an old resource. Crossposting to dev@nuttx.apache.org -- .-.---.-.--. | Michal Lyszczek | Embedded C, Linux | Company Address | .-. open source | | +48 727 564 419 | Software Engineer | Leszczynskiego 4/29 | oo| supporter | | https://bofc.pl `.--: 50-078 Wroclaw, Pol | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^-^--' signature.asc Description: PGP signature
Re: [nuttx] nuttx.org going away
On 2020-09-16 06:34:04, patacongo wrote: > > > Wouldn't it be better to at least simply write "project moved to > > nuttx.apache.org <http://nuttx.apache.org>" and maybe some usefull links > like wiki, mailing > > list, git repo etc? Right now someone might think project is dead > > or something if one visits that site from an old resource. > > Sure, but the problem is that nuttx.org is not a website. It is just a > domain name that I own that is parked at GoDaddy.com. It could re-direct, > but it cannot serve up any pages. Well, someone could host such simple site on his own webserwer. It would be best if that was someone trustworthy so he doesn't replace links with malicious ones somewhere in the future. I could host it on my server if you wish. -- .-----.---.-.--. | Michal Lyszczek | Embedded C, Linux | Company Address | .-. open source | | +48 727 564 419 | Software Engineer | Leszczynskiego 4/29 | oo| supporter | | https://bofc.pl `.--: 50-078 Wroclaw, Pol | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^-^--' signature.asc Description: PGP signature
Re: [nuttx] nuttx.org going away
On 2020-09-16 07:52:48, patacongo wrote: > > I could host it on my server if you wish. > > I can't transfer the name to anyone else. The name now belongs to the > Apache Software Foundation (or it will if/when the project graduates). No, no. I would never suggest to tranfer domain rights to me. You either (1) specify DNS server for the domain (that will point to my dns server) or (2) you manage your own DNS zone and only add "A" record and point it to my server. (2) is definately a way to go, since (1) allows me to setup subdomains and even mail addresses with nuttx.org domain, while (2) will allow me to control contents of single "http://nuttx.com"; domain - which of course you can revoke by removing "A" record in your DNS zone. Mind that (2) will also allow me to, for example do 'ssh nuttx.org', which I will be able to redirect anywhere. So yeah, you really need to ask yourself the question if you can afford to give such power to some random dude on the net. I'm not saying I will do any of it. But how can you know? -- .-.---.-.--. | Michal Lyszczek | Embedded C, Linux | Company Address | .-. open source | | +48 727 564 419 | Software Engineer | Leszczynskiego 4/29 | oo| supporter | | https://bofc.pl `.--: 50-078 Wroclaw, Pol | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `--^--^-^--' signature.asc Description: PGP signature
iMXRT boards linker scrips
Hi everyone, I was taking a look into Teensy 4.x ld scripts. They are mainly copied from imxrt1060-evk and they seem to be working fine, but I´ve run into some problems during recent work on imxrt_flexcan <https://github.com/michallenc/ incubator-nuttx/commits/can-rewrite/arch/arm/src/imxrt/imxrt_flexcan.c> so I ´ve also checked ld scripts. Pavel Píša sugested to change section alignement to 16 byte and to remove _eronly = ABSOLUTE(.); as it might couse free space after alignement. We also added _eronly = LOADADDR(.data); after data sections. The whole change is in this commit <https://github.com/ michallenc/incubator-nuttx/commit/77a1c157907eff75e514125c5be09a2671342cae> (do not mind the changes in memory size). The question is we are not sure whether these changes are actually correct (my problems with CAN were coused by my mistakes during rewrite process and wer not related to ld scripts). It seems there is no change in running NuttX on Teensy with old or new ld scripts. It would be great if someone with more understading of binutuls could shed some light into this. If these changes are correct, then they should be also made into imxrt1060-evk, imxrt1050-evk and imxrt1020-evk aswell. PS: There has been some discussion about NuttX being involded in GsoC under Apache flag, was there any further development? Best regards, Michal Lenc
Re: Troubles with CAN bus on STM32 Nucleo-F446RE
Hi, I contributed the board level CAN driver support for Nucleo F446RE board few months ago and I did some tests of receiving and transmitting CAN messages with a low cost WCMCU-230 transceiver (https://www.aliexpress.com/item/ 32686393467.html). It was working fine, actually if you configure and compile ./tools/configure.sh nucleo-f446re:can and run an example application "can", it should send 100 messages over CAN1 (RX PB_8 pin, TX PB _9 pin) unless there were some recent major changes to STM32 CAN driver. If I remember correctly, I noticed some problems when the application was in read and write mode instead of just single read or single write mode. I am not sure whether it was the same problem you describe as it was some time ago. I also did small tests with pysimCoder using maxon motor CAN block and it was also transmitting messages without any obvious problems. I haven´t tried receiving thought. I hope this helps. Best regards, Michal Lenc -- Původní e-mail -- Od: Roberto Bucher Komu: dev@nuttx.apache.org Datum: 7. 7. 2021 17:23:35 Předmět: Troubles with CAN bus on STM32 Nucleo-F446RE "Hi I'm trying to send messages using the CAN bus on the nucleo-f446re. The RX and TX of the STM32 is connected to a MIKROE transceiver (the same working without problems with the nucleo-STM32F746ZG board, but the bus stop after 8 messages (I think that stops because of the full output buffer...) Does somebody reaches to communicate with CAN bus using this board? Thanks in advance BR Roberto "
Tickless mode for iMXRT MCU
Hello, I´ve finished the implementation of tickless mode support for iMXRT MCU, which is a part of my Google Summor of Code project (https://cwiki.apache. org/confluence/display/NUTTX/%5B2021%5D+NuttX+Support+for+Rapid+Control+ Applications+Development+with+pysimCoder). The source code can be found here in my NuttX fork (https://github.com/michallenc/incubator-nuttx/blob/imxrt- tickless/arch/arm/src/imxrt/imxrt_tickless.c), I used the alarm option to take the advantage of using just one timer running in free-run mode. I did some tests with applications (ADC reading example and control application of DC motor designed with pysimCoder) and they are working fine, but command "sleep" bothers me a little bit. When I compile normal NuttX nsh configuration with tickless mode, "sleep 2" is accurate and takes about 2.0001 seconds. But when I use some bigger configuration (like configurating PWM, qencoder, GPIO, ethernet and so on for DC motor control), "sleep 2" is much less accurate. Sometimes it really takes 2 seconds, but sometimes I get values like 1.9947 (I am using "time" command). I did found out that sleep command takes one tick more in normal mode, can some of those inaccuracies also happen in tickless mode? The other source of the inaccuracy can be in clock frequency. I use 32 kHz clock source, but this value cannot be properly represented by CONFIG_USEC_ PER_TICK, which I set to 31 (which is aproximately 32.25 kHz). But 32 kHz clock source seems to be the only possible in iMXRT as others are to hight (tens or hundreds of MHz) and can´t be represended by the timer prescaler divider. Did anyone have similar problems when implementing tickless mode for some platforms? Thanks for your inputs. Best regards, Michal Lenc
Re: Tickless mode for iMXRT MCU
Hi Alan, thanks for the link! I will take a look into it. Best regards, Michal Lenc -- Původní e-mail -- Od: Alan Carvalho de Assis Komu: dev@nuttx.apache.org Datum: 11. 7. 2021 16:19:59 Předmět: Re: Tickless mode for iMXRT MCU "Hi Michal, Please take a look at this wiki page, it could help you to understand the issue with sleep take one more context switch cycle: https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays Unfortunately the Timer Hook that could help you in this case will not work in Tickless mode (according with the wiki). BR, Alan On 7/11/21, Michal Lenc wrote: > > Hello, > > > > > I´ve finished the implementation of tickless mode support for iMXRT MCU, > which is a part of my Google Summor of Code project (https://cwiki.apache. > org/confluence/display/NUTTX/%5B2021%5D+NuttX+Support+for+Rapid+Control+ > Applications+Development+with+pysimCoder). The source code can be found > here > in my NuttX fork (https://github.com/michallenc/incubator-nuttx/blob/imxrt - > tickless/arch/arm/src/imxrt/imxrt_tickless.c), I used the alarm option to > take the advantage of using just one timer running in free-run mode. I did > some tests with applications (ADC reading example and control application > of > DC motor designed with pysimCoder) and they are working fine, but command > "sleep" bothers me a little bit. > > > > > When I compile normal NuttX nsh configuration with tickless mode, "sleep 2" > > is accurate and takes about 2.0001 seconds. But when I use some bigger > configuration (like configurating PWM, qencoder, GPIO, ethernet and so on > for DC motor control), "sleep 2" is much less accurate. Sometimes it really > > takes 2 seconds, but sometimes I get values like 1.9947 (I am using "time" > command). I did found out that sleep command takes one tick more in normal > mode, can some of those inaccuracies also happen in tickless mode? > > > > > The other source of the inaccuracy can be in clock frequency. I use 32 kHz > clock source, but this value cannot be properly represented by CONFIG_USEC _ > PER_TICK, which I set to 31 (which is aproximately 32.25 kHz). But 32 kHz > clock source seems to be the only possible in iMXRT as others are to hight > (tens or hundreds of MHz) and can´t be represended by the timer prescaler > divider. Did anyone have similar problems when implementing tickless mode > for some platforms? > > > > > Thanks for your inputs. > > > Best regards, > Michal Lenc "
Re: Tickless mode for iMXRT MCU
Hi Greg, thanks for your advices. > If you use 32.768KHz clock source, then there is a small error in every > time conversion since 1/32768 cannot be represented in microseconds. > Normally, this will result in small errors as you have noted. However, > in a very busy system with man timers, that error builds up and can be > quite large... like 50% error! See the above reference. I managed to find the (hopefully) right clock value for the GPT timer. If I use peripheral clock at 16.6 MHz (which is already the set value for iMXRT MCU) as a clock source, this value can be divided by 1660 prescaler for 100 usec CONFIG_USEC_PER_TICK or by 166 prescaler for 10 usec CONFIG_USEC_PER_ TICK. Both values would mean that the clock frequency of GPT timer is equal to CONFIG_USEC_PER_TICK (or to its frequency more precisely). I did some tests and it seems that those inaccuracies I was having with 32.768 kHz clock source are not a problem now. I will do some further tests before creating the PR thought. Best regards, Michal Lenc
Using PWM with less channels than defined in CONFIG_PWM_NCHANNELS
Hello, currently most of the PWM drivers (STM32, NRF52, iMXRT etc.) use for loop from 0 to CONFIG_PWM_NCHANNELS when setting multiple channels in function pwm_start, for example here in STM32 code <https://github.com/apache/ incubator-nuttx/blob/master/arch/arm/src/stm32/stm32_pwm.c#L4386>. This works fine when CONFIG_PWM_NCHANNELS is equal to the number of used channels, but there can be situations when less channels are used. For example if I configure PWM1 with 2 channels and PWM2 with 3 channels, CONFIG _PWM_NCHANNELS would have to be 3, but that would mean the loop would go from 0 to 3 also for PWM1 instead of just from 0 to 2. This resulted in hard fault when I tried something similar in an application designed in pysimCoder as info->channels[2].channel is not defined because channel 3 is not used for PWM1. I was thinking about adding something like int used_channels; to include/ nuttx/timers/pwm.h <https://github.com/apache/incubator-nuttx/blob/master/ include/nuttx/timers/pwm.h#L137> and then defined number of used channels in the application (the same way as defining frequency, channel number and duty cycle) rather than to have a global definition CONFIG_PWM_NCHANNELS. That would also mean replacing the for loops in pwm_start function (and maybe some other lines of code) so there would be something like "for (i = 0; ret == OK && i < info->used_channels; i++)" instead of "for (i = 0; ret == OK && i < CONFIG_PWM_NCHANNELS; i++)". The tricky part of this is multiplatform change that would probably result in some bugs that I would not be able to test as I don´t have all the boards with those MCUs. Or am I missing something and using less channels than defined in CONFIG_PWM_NCHANNELS should actually work? Thanks for your inputs. Best regards, Michal Lenc
Option to break for loop in PWM driver code by -1 channel number
Hello,
the PWM driver currently uses channel number 0 for channels that are not
supposed to be used. During the meeting for Google Summer of Code project
NuttX Support for Rapid Control Applications Development with pysimCoder
(information about the project can be found here https://cwiki.apache.org/
confluence/display/NUTTX/%5B2021%5D+NuttX+Support+for+Rapid+Control+
Applications+Development+with+pysimCoder) with Professor Bucher and Dr. Píša
we discussed an option to add channel number -1 as a "stop" value. That
would indicate that it is not necessary to check the other channels and that
they all can be skipped. This can be useful when for example just one
channel out of x is used and thus there is no need to waste time by checking
the others. The example of the code can be found here <https://github.com/
michallenc/incubator-nuttx/blob/teensy-dc/arch/arm/src/imxrt/imxrt_flexpwm.
c#L920>. The key part is:
for (int i = 0; ret == OK && i < CONFIG_PWM_NCHANNELS; i++)
{
/* Enable PWM output for each channel */
if (info->channels[i].channel == -1)
{
break;
}
if (info->channels[i].channel != 0)
{
...
The advantage is that this addition would not damage current drivers or
already developed applications in any way but would just add the possibility
to break the loop from the application level code. It would be great if the
options like 0 and -1 would be standardized and documented somewhere
(probably extend this page https://nuttx.apache.org/docs/latest/components/
drivers/character/pwm.html).
If there is no major problem with adding -1 as a "stop" value to all PWM
drivers I can create a PR during the following days.
Best regards,
Michal Lenc
Possibility of merging few lcd drivers into one file
Hi all, I was taking a look into the current state of files for LCD drivers (drivers/lcd/) and I am wondering about your opinion about this. Is there any particulal reason not to merge few of those drivers into one file? I am talking mostly about merging files st7735.c, st7789.c and st7796.c (not merged into mainline yet, just in my repo) into file st77xx.c (and do the same with header files). It still could be configurable in menuconfig separately as ST7735 or ST7789, but source codes would be in one file. It should not be that hard to change this as st7789.c and st7796 are mostly copies of st7735.c. Perhaps drivers for ST7565 and ST7567 could be also merged into ST75XX, but that would take more job as the source codes seems to be different. Thanks Best regards, Michal Lenc
Re: Possibility of merging few lcd drivers into one file
Hi, > I think this is a good idea, case they are really similar and you don't need to use tons of #ifdef. I think few of the #ifdefs would be used in pre processor definition section as It would be great to let predefined displays resolutions but other than that there should not be many of them. I will get into this perhaps later this week or during the next, firstly I want to figure out what went wrong with Tickless Mode for iMXRT (desrcibed here https://github.com/apache/ incubator-nuttx/issues/4442). Best regards, Michal Lenc -- Původní e-mail -- Od: Alan Carvalho de Assis Komu: dev@nuttx.apache.org Datum: 30. 8. 2021 15:22:21 Předmět: Re: Possibility of merging few lcd drivers into one file "Hi Michael, I think this is a good idea, case they are really similar and you don't need to use tons of #ifdef. Other driver that needs some care is the OLED SSD1106/SSD1306, there are many entries in the menuconfig for the same driver. It is using some specific manufacturer name instead of the IC controller. BR, Alan On 8/30/21, Michal Lenc wrote: > > Hi all, > > > > > I was taking a look into the current state of files for LCD drivers > (drivers/lcd/) and I am wondering about your opinion about this. Is there > any particulal reason not to merge few of those drivers into one file? I am > > talking mostly about merging files st7735.c, st7789.c and st7796.c (not > merged into mainline yet, just in my repo) into file st77xx.c (and do the > same with header files). It still could be configurable in menuconfig > separately as ST7735 or ST7789, but source codes would be in one file. It > should not be that hard to change this as st7789.c and st7796 are mostly > copies of st7735.c. Perhaps drivers for ST7565 and ST7567 could be also > merged into ST75XX, but that would take more job as the source codes seems > to be different. Thanks > > > Best regards, > Michal Lenc "
Implementing QSPI driver in SPI mode
Hello all, some chips from SAME70 family (J21 for example) do not have an SPI driver but use QSPI that can be run either in serial memory mode or in Master SPI mode. The config options in samv7 arch seems to be already prepared for that as SAMV7_QSPI_IS_SPI is selected for some chips but current sam_qspi.c implements only serial memory mode. There seems to be no working example of QSPI working as SPI in NuttX generally (all the implementions seems to be written just for the memory access) so I´d like to consult which implementation is prefered as I am not sure whether some similar discussions took place in the past. The QSPI would need to support the SPI interface defined in struct spi_dev_s in order to ensure compatibility with existing applications and drivers (LCD displays for example) which use SPI. The option would be to add this structure next to qspi_dev_s in arch specific drivers (in SAM case here https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam _qspi.c#L159) and implements the specific SPI operations (send, exchange, command/data etc.) in that file. The driver would then access either qspi_ dev_s structure or spi_dev_s structure based on the configuration option for the chip and would operate with that structure. Would this be a suitable option or were there some other plans regarding implementing SPI functions to QSPI? Thanks Best regards, Michal Lenc
Re: Implementing QSPI driver in SPI mode
Hi, yes, I think the code duplication should not be that bad. Having separate drivers sam_spi.c for classic SPI, sam_qspi.c for QSPI in serial memory mode (current implementation) and sam_qspi_spi.c or something like that for SPI over QSPI would be an option then. Thanks. Best regards, Michal Lenc -- Původní e-mail -- Od: Gregory Nutt Komu: dev@nuttx.apache.org Datum: 15. 10. 2021 0:01:34 Předmět: Re: Implementing QSPI driver in SPI mode "> > The QSPI would need to support the SPI interface defined in struct spi_dev_s > in order to ensure compatibility with existing applications and drivers (LCD > displays for example) which use SPI. The option would be to add this > structure next to qspi_dev_s in arch specific drivers (in SAM case here > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam > _qspi.c#L159) and implements the specific SPI operations (send, exchange, > command/data etc.) in that file. The driver would then access either qspi_ > dev_s structure or spi_dev_s structure based on the configuration option for > the chip and would operate with that structure. Would this be a suitable > option or were there some other plans regarding implementing SPI functions > to QSPI? Thanks I would be inclined to implement this as a separate SPI driver rather that to try to make the QSPI driver to both roles. That would be cleaner and much less complex. I think that the amount of code duplication would not be very much since there is not a lot of overlap in data structures, interface functions, etc. INVIOLABLES.md: "Sometimes Code Duplication is OK" "
Re: SPI with DMA on SAME70
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) 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). 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
Hello Simon, I had noticed your DMA fix PR (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. 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 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 > "
Serial RX DMA polling
Hi all, serial drivers use periodic polling for DMA receive callback to ensure the reception of bytes that were not taken by DMA interrupt. There are functions like stm32_serial_dma_poll(void) that should be periodically called from a timer for this purpose. However I haven´t been able to find any "example" usage in the NuttX mainline. My first thoughts were to implement the timer directly to the driver (like in ADC drivers) but stm32_serial_dma_poll(void) is not private so I guess it is not supposed to be called from stm32_serial.c but rather from board level section? Is there any consensus on how to use the periodic polling? Thanks. Best regards, Michal Lenc
RE: Serial RX DMA polling
Hi David, > https://github.com/PX4/PX4-Autopilot/blob/master/boards/px4/fmu-v5x/src/ init.cpp#L243-L247 that´s exactly what I was looking for, thanks! Best regards, Michal Lenc -- Původní e-mail -- Od: David Sidrane Komu: dev@nuttx.apache.org Datum: 7. 3. 2022 15:20:08 Předmět: RE: Serial RX DMA polling "Hi Michal, > rather from board level section Yes Have a look at this example. https://github.com/PX4/PX4-Autopilot/blob/master/boards/px4/fmu-v5x/src/ init.cpp#L243-L247 -Original Message- From: Michal Lenc Sent: Sunday, March 6, 2022 2:38 PM To: dev@nuttx.apache.org Subject: Serial RX DMA polling Hi all, serial drivers use periodic polling for DMA receive callback to ensure the reception of bytes that were not taken by DMA interrupt. There are functions like stm32_serial_dma_poll(void) that should be periodically called from a timer for this purpose. However I haven´t been able to find any "example" usage in the NuttX mainline. My first thoughts were to implement the timer directly to the driver (like in ADC drivers) but stm32_serial_dma_poll(void) is not private so I guess it is not supposed to be called from stm32_serial.c but rather from board level section? Is there any consensus on how to use the periodic polling? Thanks. Best regards, Michal Lenc "
Re: Anyone using SAMv7 PWM?
Hello, > Recently I've tried to use PWM on SAMe70 based board. I tried to execute > PWM example from apps. The PWM on SAMv7 seems to be not functional, at > least I observe only that pin goes high when PWM start is executed and the > goes to low when PWM stop is executed. what king of configuration have you tried? I tested the configuration same70 -xplained:pysim on a real time control of RC plant <https://gitlab.fel.cvut.cz/otrees/nuttx-demos/-/tree/master/ platforms/same70/rc-control> with SAM E70 Xplained board few days ago. You should be able to run a PWM example app in this config too. The pins setup in board level section can be found here: <https://github.com/apache/incubator-nuttx/blob/master/boards/arm/samv7/same 70-xplained/include/board.h#L345> I will double check tomorrow if the configuration does not work for you. Best regards, Michal Lenc -- Původní e-mail -- Od: Petro Karashchenko Komu: dev@nuttx.apache.org Datum: 16. 5. 2022 18:36:49 Předmět: Anyone using SAMv7 PWM? "Hello, Recently I've tried to use PWM on SAMe70 based board. I tried to execute PWM example from apps. The PWM on SAMv7 seems to be not functional, at least I observe only that pin goes high when PWM start is executed and the goes to low when PWM stop is executed. Is anyone using PWM with SAMv7 based board? Maybe I'm missing something? Best regards, Petro "
Re: Anyone using SAMv7 PWM?
Hello > CONFIG_EXAMPLES_PWM=y > CONFIG_PWM=y > CONFIG_SAMV7_PWM0=y > CONFIG_SAMV7_PWM0_CH2=y I used your configuration options and there indeed seems to be a problem. I also wasn´t able to get any PWM output if the driver was configured as a single channel with CONFIG_PWM_MULTICHAN disabled. The PWM works if CONFIG_ PWM_MULTICHAN is selected and CONFIG_PWM_NCHANNELS is set as 2 or more. So far I am not sure what causes this, my initial debugging did not reveal any issues: correct functions are called, correct pin is configured, value is written to correct registers etc. Or at least it seems to be correct. I will need to take a further look into this during a weekend. So far a quick workaround is to enable multiple channel support and set two or more channels. The additional channel does not need to have an actual output, if you set the channel number to 0 it will be skipped. I will let you know when I discover what causes this. The driver is mostly a derivate from imxRT PWM driver and single PWM worked fine there if I recall correctly. Best regards, Michal Lenc" "
Re: Wikipedia: "Proposal deletion of NuttX"
Hi Alan, as a former administrator on Czech Wikipedia I personally do not see a reason for a deletion. But it may be the standards on English Wiki are different, each language mutation has its own rules. What could help from my point of view would be an addition of "history" chapter or something like that and a deletion of the long lists of key futures, platforms and drivers. Those generally should not be included in a good Wikipedia article. If the readed wants to know for example all supported platforms he should refer to NuttX documentation. Still I do not see this as a reason to delete the page. For now I would reccomend to ask user MrsSnoozyTurtle on his talk page (https://en.wikipedia.org/wiki/User_talk:MrsSnoozyTurtle) what parts of the article does he consider to be promotional so we know what we need to change. Best regards, Michal Lenc -- Původní e-mail -- Od: Alan Carvalho de Assis Komu: dev Datum: 21. 7. 2022 13:10:12 Předmět: Wikipedia: "Proposal deletion of NuttX" "Hi team, I received this email and I don't know what we need to do to avoid it: MrsSnoozyTurtle left a message on *your talk page* in "*Proposed deletion of NuttX*". The article NuttX has been proposed for deletion because of the following concern: Promotional article While all constructive contributions to Wiki "
Re: ADC device close and IRQ
Hi, > The easy option is to comment out the two calls, but I don't know if that' s > deemed acceptable, especially as other adc drivers do the same? I do not think this is correct since it is better to disable and detach the interrupt when we close the device. Instead I think the the enabling and attaching should be moved from sam_adc_ initialize() to sam_adc_setup() which is called every time the driver is opened from the application. Similar to SAMv7 ADC driver: https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam _afec.c#L845 This would ensure the interrupt is enabled and attached when the driver is opened and disabled and detached when it is closed. Best regards, Michal Lenc
W25Nx NAND flash support
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
Re: W25Nx NAND flash support
Hi, thank you all for your inputs and links. I will take a look into it. Best regards, Michal Lenc -- Původní e-mail -- Od: Simon Filgis Komu: dev@nuttx.apache.org Datum: 25. 2. 2023 14:43:33 Předmět: Re: W25Nx NAND flash support "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 > > > "
Configuration of external RTC results in build error
Hello, there seems to be a possible build error hidden in configuration of external RTC. If configure CONFIG_RTC and CONFIG_RTC_EXTERNAL to use external RTC the build ends with following error: undefined reference to `up_rtc_initialize' This is caused by lines https://github.com/apache/nuttx/blob/master/sched/clock/clock_initialize.c#L 218 and https://github.com/apache/nuttx/blob/master/include/nuttx/arch.h#L2272 that declare and call function up_rtc_initialize which however I suppose is not used since external RTC is to be configured. This happens since pull request #5232 (https://github.com/apache/nuttx/pull/5232) which removed && ! defined(CONFIG_RTC_EXTERNAL) from files mentioned above. The quick fix so far is to add the constrain of disabled CONFIG_RTC_EXTERNAL back as suggested here (https://github.com/michallenc/incubator-nuttx/commit/bc04eb9 d891c44a6b41bb0badf34636e24e63b61). Some ideas or objections? I am not sure if there was not some other change that would require different configuration of external RTC. Best regards, Michal Lenc
RTC synchronization with system time
Hello all, NuttX offers a function clock_synchronize() that synchronizes system clock with clock from RTC (internal or external). The synchronization is done during board initialization and I suppose this can also be called from an application level if required. However I was not able to find any implementation that would automatically synchronize system time with (correct) values from RTC if system clock drifts from real time. It seems the only possible option is to "force" the synchronization by calling the mentioned clock_synchronize() function periodically from application level. What is your view on adding some sort of automatic synchronization that would ensure system clock stays in sync with RTC (or at least error is less than some value) even when i drifts away from "real time"? Quite simple solution is to let clock_gettime() to update base time after N reads however this would add some computation complexity to gettime (I2C communication delay for external RTC etc.) and I am not sure if we really want this inside clock_gettime(). Best regards, Michal Lenc
Re: RTC synchronization with system time
> You wouldn't really do this from application level, right? No, I don't want to do this from application level hence why I am looking for an alternative. NuttX also has function clock_resynchronize() that should solve the problem with time going backwards but not sure if it has ever been tested and used. Thank you for the link and issue about adjtime(), that seems like a good alternative and way to go. Best regards, Michal Lenc -- Původní e-mail -- Od: Gregory Nutt Komu: dev@nuttx.apache.org Datum: 21. 3. 2023 0:20:43 Předmět: Re: RTC synchronization with system time "You wouldn't really do this from application level, right? There is currently no POSIX-compatible application interface to do that. But you could implement a kernel thread that is started in your board initialization logic that can call clock_synchronize() according to whatever criteria you need. I suppose a standard kernel thread could also be implemented in sched/clock if such a one-size-fits-all solution can be imagined. You might check out logic in sched/clock for CONFIG_CLOCK_TIMEKEEPING. That is used primarily for adjusting the time to properly track time from NTP. Seems to me that that is essentially the same issue: Keeping two clocks in agreement. On 3/20/2023 4:20 PM, Michal Lenc wrote: > Hello all, > > > > NuttX offers a function clock_synchronize() that synchronizes system clock > with clock from RTC (internal or external). The synchronization is done > during board initialization and I suppose this can also be called from an > application level if required. However I was not able to find any > implementation that would automatically synchronize system time with > (correct) values from RTC if system clock drifts from real time. It seems > the only possible option is to "force" the synchronization by calling the > mentioned clock_synchronize() function periodically from application level. > > > > > What is your view on adding some sort of automatic synchronization that > would ensure system clock stays in sync with RTC (or at least error is less > than some value) even when i drifts away from "real time"? Quite simple > solution is to let clock_gettime() to update base time after N reads however > this would add some computation complexity to gettime (I2C communication > delay for external RTC etc.) and I am not sure if we really want this inside > clock_gettime(). > > > > > Best regards, > Michal Lenc > "
Re: PCF8575 driver for NuttX
Hi,
Perhaps I am too late to the discussion and some of those stuffs were
already said but I use PCF8575 on a custom board so I think a can help a bit
with that.
> I'm trying to access the PCF8575 device from my application on NuttX to
make it light up LEDs. I'm not really sure how to implement it, but this is
what I've got:
The easiest way if you want to use PCF8575 for LEDs is to register those as
GPIOs using CONFIG_GPIO_LOWER_HALF. First you have to initialize I2C and
register the expander (you can do it in BSP layer).
struct pcf8575_config_s g_pcf8575_cfg =
{
.address = PCF8575_I2C_ADDRESS,
.frequency = PCF8575_I2C_FREQ,
};
struct i2c_master_s *i2c;
struct ioexpander_dev_s *ioe;
i2c = sam_i2cbus_initialize(TWIHS0_BUS);
ioe = pcf8575_initialize(i2c, &g_pcf8575_cfg);
Then you can register the pins.
IOEXP_SETDIRECTION(ioe, 0, IOEXPANDER_DIRECTION_OUT);
gpio_lower_half_byname(ioe, 0, GPIO_OUTPUT_PIN, "led_red");
IOEXP_WRITEPIN(ioe, 0, 1);
etc.
The pin is registered as dev/led_red and you can access it from your
application using classic GPIO interface (take a look at examples/gpio).
Writing multiple pins is a bit trickier, you can use IOEXP_MULTIWRITEPIN but
this requires ioexpander_dev_s structure to be available in application
layer (which is possible, but you would have to do the whole
initialization in application layer and as someone already mentioned, this
might not be thread safe).
But accessing pins one by one should be straightforward with CONFIG_GPIO_
LOWER_HALF option. Hope this helps.
Best regards,
Michal Lenc
Access GPIO pins over Lua
Hello, has anyone tried accessing GPIO pins over Lua? I have tried LED example presented at NuttX workshop a year or two ago and userled driver is working fine, but using the same code on GPIO registered pin fails (assert on open). I suppose io.open is implemented only for userleds and does not work for GPIO? Thanks. Best regards, Michal Lenc
Re: System time issue with external RTC
Hi, the right way to keep the system time in sync with external RTC is adjtime() function. https://man7.org/linux/man-pages/man3/adjtime.3.html NuttX also has its own implementation of adjtime() https://github.com/apache/nuttx/blob/master/sched/clock/clock_adjtime.c, so you can use it. Just enable CONFIG_CLOCK_ADJTIME option to include it into compiled functions. You will need some periodic calculations of time difference between adjtime and RTC clock in your application (some thread that wakes up from time to time) and then to call adjtime() to adjust the system clock. The function does not do time jump here, it just speeds up or slows down hardware timer to adjust the time. Best regards, Michal On 5/31/24 10:03, cheshmedzh...@gmail.com wrote: > Hi all, > > > > The testing conditions are: nuttx 2.12 runs on NUCLEO-U5A5ZJ-Q board. I have > high accurate external RTC connected to one of i2c busses. > > When system runs for a long time - 2-3 days or more the time returned by > date command is not accurate. When I reboot the system the system time > become accurate (this is normal it is adjusted with RTC in boot process). > > So, the question is: What is right way to keep system time in sync with > external RTC? > > > > Best regards > > > >
Re: Problems Flashing
On 2024-06-12 07:35:27, Felix Leonbacher wrote: > Hey Guys, > > I am an embedded systems Student in Germany and wanted to use ur apache > nuttx in my project. Sadly I am unable to flash it. I have a STM32F207 > nucleo-144 and when I come to > openocd -f interface/stlink-v2.cfg -f target/stm32f2x.cfg -c 'init' \ > -c 'program > nuttx/nuttx.bin verify reset' -c 'shutdown', > it says checksum mismatch Hmm... just a guess, could be that you are missing flashing address? For STM it should be 0x0800, so maybe try doing openocd -f interface/stlink.cfg -f target/stm32f2x.cfg -c 'program nuttx.bin 0x0800' Also, it may be wise to paste whole log from openocd, there may be information you think is useless but could be vital. Second guess, try omitting 'verify', I flash without it in debug sessions and never had any problem with program. -- .-----.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: How to demystify some myths about NuttX
On 2024-07-09 09:49:16, Alan C. Assis wrote:
> I think many people outside our community have a misconception about NuttX:
> They think it is a Linux/Unix RTOS that needs to have a shell integrated
> into it.
>
> Note that all boards are required to have a "nsh" board profile, it was a
> suggestion/requirement to confirm that the system works correctly. There is
> not wrong with it, but it sends a message that NuttX needs it to exist.
>
> How to fix it?
I think I would be good if nuttx had something like /sbin/init that would
do some very simple service management. Then you could just tick
"Start NSH after boot up". Programs would probably be had to added via
some compile-time header file that would look like that:
| struct program
| {
| const char *name;
| int priority;
| int stack_size;
| main_t entry_point;
| int pid;
| };
|
| struct program programs[] =
| {
| #ifdef CONFIG_EXAMPLES_NSH
| { "console", 50, 2048, nsh_consolemain },
| #endif
| #ifdef CONFIG_SOME_DAEMON
| { "some-custom-daemon", 50, 2048, daemon_function },
| #endif
| { NULL, 0, 0, NULL }
| };
And program in its simplest form would do:
| #include
| int main(int argc, char *argv[]) {
| for (int i = 0; programs[i].name != NULL; ++i) {
| struct program *p = &programs[i];
| printf("starting: %s\n", p->name);
| p->pid = task_create(p->name, p->priority, p->stack_size,
| p->entry_point, NULL);
| }
| for (;;) sleep(UINT_MAX);
| }
I think such init could also handle all initialization code (so not only
starting up daemons). It could be more clear than current board initialization
routines which are a little bit confusing (for me at least).
That would solve 2 problems. It would be very clear that NSH is not needed, and
user would have an easy way to start it's own daemons/applications.
> Suggestions about how to proceed to archive it are welcome.
> Probably we will need collective help to archive it for all boards.
Other problem I've seen is bad (or rather lack thereof) press. Each time
I propose nuttx for some project it's a lot of hesitance and ultimately
decision to go with zephyr becuase it "supports more things". Which is
a lie, because with my experience zephyr has a lot of demos just to show
off "how many things they support". But it's all demo and nor production
quality. Nevertheless - this sells. And later when it's clear that zephyr
was lying - it's too late to go with anything else because months of work
was already put into zephyr, so noone will start over.
So nuttx definiately lacks press and exposure. Basically noone I worked with
heard about nuttx until I mentioned that. A lot of programmers are hyped
when I explain what and how it does things - but it all ends up with zephyr
because of "all the supported hardware it has".
For ppl to consider nuttx, they first need to hear about it. People (especially
useless managers) will need benchmarks - like how much flash/ram it uses.
How it performs. Will their hardware be supported.
It would not hurt for things to be more user friendly. I admit, initializing
zephyr is easy. Unpack SDK, west init, compile, flash and you are done.
And nuttx? Download and put compiler in path. Clone nuttx AND apps in same
directory. Configure. Compile. Learn your debugger to flash. On zephyr you
do 'west flash' and it knowns which discovery board is used and it uses
apropriate tool and arguments. This is good, I will admit it.
So nuttx would need some SDK in my opinion. Package with binary compilers and
flash utilities. "make flash" should just perform flash on specific board
without user knowing what tools is needed. "make debug" should start GDB
session.
A lot of beginners will be put off becuase of things like that. If they could
just do "./install-sdk.sh && ./init-nuttx && cd nuttx &&
./tools/configure.sh nucleo-whatever && make && make flash" and start playing
around - this would definiately help getting beginners.
Anegdotal (but still) proof. 10 years ago I was researching RTOSes. I really
wanted to use nuttx on stm32 back then. But I had a lot of problems just
compiling and running anything on discovery board. I was kinda put off, team
leader decided to screw it and go with another solution. I finally learnt it
at home and love it ever since, but damage was already done and nuttx in that
project was forgotten.
Sorry for long post, here's a potato: 🥔
--
.-.---.--.-.
| 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 |
`--^--^--^-'
signature.asc
Description: PGP signature
Re: How to improve/simplify NuttX initialization processes?
On 2024-07-09 10:06:53, Alan C. Assis wrote:
> How can we improve things?
>
> How can we simplify this?
I am just copy pasting my message from other thread, as I did not see
that one in time :) So my proposition is:
I think I would be good if nuttx had something like /sbin/init that would
do some very simple service management. Then you could just tick
"Start NSH after boot up". Programs would probably be had to added via
some compile-time header file that could look like that:
| struct program
| {
| const char *name;
| int priority;
| int stack_size;
| main_t entry_point;
| int pid;
| };
|
| struct program programs[] =
| {
| #ifdef CONFIG_EXAMPLES_NSH
| { "console", 50, 2048, nsh_consolemain },
| #endif
| #ifdef CONFIG_SOME_DAEMON
| { "some-custom-daemon", 50, 2048, daemon_function },
| #endif
| { NULL, 0, 0, NULL }
| };
And program in its simplest form would do:
| #include
| int main(int argc, char *argv[]) {
| for (int i = 0; programs[i].name != NULL; ++i) {
| struct program *p = &programs[i];
| printf("starting: %s\n", p->name);
| p->pid = task_create(p->name, p->priority, p->stack_size,
| p->entry_point, NULL);
| }
| for (;;) sleep(UINT_MAX);
| }
I think such init could also handle all initialization code (so not only
starting up daemons). It could be more clear than current board initialization
routines which are a little bit confusing (for me at least).
That would solve 2 problems. It would be very clear that NSH is not needed, and
user would have an easy way to start it's own daemons/applications.
--
.-----.---.--.-.
| 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 |
`--^--^--^-'
signature.asc
Description: PGP signature
Re: How to demystify some myths about NuttX
On 2024-07-09 17:20:26, Sebastien Lorquet wrote: > On 09/07/2024 17:06, michal.lyszc...@bofc.pl wrote: > > I think I would be good if nuttx had something like /sbin/init that would > > do some very simple service management. Then you could just tick > > "Start NSH after boot up". > > I think you can already do this by writing an init app and using that to > spawn a shell. > > Which is wasteful on small systems since you can start the shell directly > and save memory. > > Also, nsh can execute startup scripts, which are more flexible than your > suggestion. > > A few months ago, these scripts were linked to a rigid romfs automount > system which made the whole thing very cumbersome. > > But it's more flexible now, it was improved and the romfs can be customized. > > Sebastien Yes, I agree that nsh is more flexible. But the problem is that to run these scripts you need nsh. And whole discussion is to make nsh more optional. I suppose it could be enough to move init stuff from nsh to separate program. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: How to improve/simplify NuttX initialization processes?
On 2024-07-09 09:21:32, Gregory Nutt wrote: > On 7/9/2024 9:10 AM, michal.lyszc...@bofc.pl wrote: > > I am just copy pasting my message from other thread, as I did not see > > that one in time :) So my proposition is: > > > > I think I would be good if nuttx had something like /sbin/init that would > > do some very simple service management. Then you could just tick > > "Start NSH after boot up". Programs would probably be had to added via > > some compile-time header file that could look like that: [snip] > > Starting any initialization task implies that you have already initialized > the operating system. This is fine for application level initialization but > OS level initialization must already be complete. > > The only complex thing about initialization are the chicken'n'egg problems. > For example, on DRAM-based platforms you can't execute any "normal" C code > until memory resources are initialized. Any initialization sequence must > account for the initialization and ordering requirements of all supported > platforms but must do so in a platform-independent way. > > Sweeping generalizations generally don't work for all initialization cases. I only meant to use init to replace boardctl initializations but I see your point. Well, my point still stands for most of it. Init should be a separate program that would start nsh (and other user daemons), not the other way around. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: Improving NuttX Awareness
On 2024-07-09 20:12:49, Gábor Kiss-Vámosi wrote: > Hi, > > There are two more points that I'd add: > 1. Easy to get started: have example projects that can be set up by reading > a few lines from the README. Exactly. THE most important thing in project such as this is user friendly. Once the simple program is running, you can slowly built on that in incremental fashion. If you struggle to even run "Hello World!", user will just go. People want to PROGRAM (I know, shocker, right?:)) not fiddle with environment, toolchains and flashing tools. Why is stm32cube so popular even tough it's trash? Because you just click few things and programs do work. And then you can build on that. There must be a way for people (especially beginners) to setup environment with 0 knowledge about Linux. ./tools/configure.sh script should download and install whole toolchain and setup the environment. In kconfig there should be option to select "SDK Toolchain" that would use that internal toolchain, and it should be enabled by default. Buildroot can do that. Then "make flash" should know how to flash specific board and just do it without the need of user to know flash address. Just look at buildroot. You just clone it. make defconfig, call make, and you are done. You have nice working baseline on which you can work. Nuttx is just too much hassle to setup on fresh environment. Competition is strong. Nuttx is for strong power users. But that will only invite power users. Most important thing to understand is - that people want to program, and not play around with environment -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: Please recommend NuttX
On 2024-07-11 06:19:55, Alan C. Assis wrote: > I wasn't expecting anything different from ARM: > > https://forums.mbed.com/t/important-update-on-mbed-end-of-life/23644/3 > > This is why I think RISC-V will win! That's right Alan, you tell them! And yeah, I agree with you. It would take him less time to edit his post than to reply to you. -- .-.---.------.-----. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Using external libraries with NuttX
Hello all, I am currently facing the problem of using external library with NuttX. The support is already prepared in mainline in directory external/ which is compiled if Kconfig and Makefile are present in the directory. This is all fine as I symlink my library to external/ directory so I get to compile the source code and have all the configuration I need. The directory looks somewhat like: external my_project Make.defs and Kconfig Kconfig and Makefile The problem is with the headers. If I use the same approach as in drivers/ or so libraries and add my headers to CFLAG, they are not accessible from an application. The only thing that works so far is adding the CFLAGs in top level Make.defs linked from the board directory; then the headers are exported and everything works fine. Is this the only possible solution so far or is there some other flag/approach how to do it more nicely? The ideal approach from my point of view would be not to edit top level Make.defs at all. Am I missing some additional flag? Thanks. Michal
Re: Using const in function arguments.
On 2024-07-11 23:36:22, Saurav Pal wrote: > Hi all, > > Suppose I have a pointer that I want to pass through function parameters. > In the function, neither is the pointer reassigned, nor is the thing it > points to modified in any form. > > So, I would assume its function argument signature to be like FAR const > struct my_struct * const ptr (The second "const" is my focus here). > Similarly for things like const uint8_t my_num, etc. as well. > > However, I have not really seen much use of specifying constants using > const (in the way I have mentioned above). Most of the examples I see are > of FAR const struct my_struct * ptr. I have heard the compiler can make > better optimizations for const, and because of this, I try to spam const > anywhere and everywhere I can. But I don't see too many such usages across > the codebase, so I was wondering why that is (or I just maybe reading the > code wrong, in which case, forgive me 🙏). Because it doesn't really make much sense to do so. *EVERYTHING* in C is passed as copy. Yes. Even pointers. Consider this | void foo(const void * const ptr); | ... | const void *mem = 0x123; | foo(mem); It means that you won't change the memory at address 0x123. It's clear. But second const actually only affects the function body itself. Even without "const ptr", you won't be able to change users "mem" variable. Even if you modify "ptr" inside "foo" you have only modified your local ptr variable - same way as if you declared variable in body. So it adds basically nothing. And ptr in fact IS NOT constant, it's just an integer (simplifying) on functions call stack. It belongs to you. Second const just bloats declaration and gives almost nothing in return. First const is very important, you know to expect function modifying (or not) what is rightfully yours. And those consts are promises anyway. Nothing stops me from modifying your const if I wanted to (well... maybe except for some hardware exception if data is really on RO medium ;)). And compiler can easily determine if something is const or not without the const keyword. | int foo = 6; | return foo * 4; Will be reduced to "24" anyway, even without "const int foo". -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: Help us to create a distributed board testing farm
Hi On 2024-07-18 16:14:20, Alan C. Assis wrote: > We are creating a testing farm for NuttX to be integrated on our CI. How is this going to work? Since, this seems like, tests will be conducted on real hardware, I assume I would have to install some daemon at my home so that CI could send commands to it to perform tests? This poses serious security risks. The only way I see it working is to have raspberry pi (or any other mini computer) in isolated network and vlan. What CI software are you going to use? I remember using Buildbot in the past, which may be good candidate, since I remember it being build just for cases like that. That is you host Master, and anyone that wants to participate in testing their arch/platform would set up a slave, which would connect to master and listen for build commands. Might be worth investigating it. I think it would be beneficial if anyone could just setup slave on his own, and then just connect to the master without any real authorization to participate in testing. I think there is a risk of such slave feeding false positives/negatives tho and someone who does not like nuttx could sabotage tests ;) -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: aarch64 boot crash when printing non-static string
On 2024-07-31 21:15:53, Matteo Golin wrote: > I cannot wrap my head around why I would be able to print a static string, > but not a non-static one. Both strings appear in the `.rodata` section of > the image when I inspect it with `objdump` as well. Even the assembly > `PRINT` macro in the arm64_head.S startup code declares the strings as > rodata. I'm not sure what the difference is here, but it's preventing me > from continuing to debug the boot process. I'm by no means very > experienced, so I feel a bit stuck with this issue. I thought I would check > if anyone here has encountered something similar. > > Any tips or pointers of what else I can check would be really appreciated! Can you maybe post stack trace from GDB after crash? Also check what address is dereferenced. Static will probably have different address than non static. aarch64 has some security and atf, maybe that is causing the problem? This is just a wild guess. Check failing instruction, dump info from it like addresses, and then do the same for working static data. Maybe this will shed some light onto this problem. It's good to know which instruction is failing and what arguments it takes. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: ESP32 - How use SPI Slave
On 2024-08-28 15:48:10, Felipe Moura Oliveira wrote: > Hello All, > > Following Gustavo instructions I was able to see it working several commits > before master. > I will open a github issue, maybe more people can look it and help us to > solve. If you have working hash, then please do "git bisect" to pinpoint offending commit. "git bisect" will hold your hand throughout the whole process. It's easy and mostly automatic. Just needs some time to rebuild and reflash. -- .-.---.------.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: RP2350 port part 2
On 2024-08-29 11:17:06, Marco Casaroli wrote: > I have some more questions for you. I start a new email thread to not > generate noise in the previous discussion. > > 1. The RP port needs some hardware (include) files from pico-sdk. Should I: Nuttx does not include nor use any of the OEM SDK. This is double edge sword. It takes longer to implement driver, but those drivers are usually better fitted, better quality and less buggy than OEM drivers. If these are only register definitions than you may be able to get away with this (if license permits it and by doing some reformating). Including code is probably a no go. > 2. (if answer to Q1 is option a, then), should I reformat the imported code > to match NuttX or I can just drop the files there without any > modifications? (they are BSD-licensed) Usually reformat won't cut it as you need to follow Nuttx specifi API. Second thing is maintaning that code. OEM code tries to handle all possible cases, so there are a lot of code. And drivers usually need only a small subset of features that is required for it to work. Not going for corner cases make code so much smaller and easier to maintaing. If you reformat OEM code, someone has to maintain it - and just copying updated file from OEM will not work. > > 3. Should I aim to make this port work on rp2040 (and rename it to rp2xxx) > - the drivers are very similar, or should I keep it separated and target > rp23xx only? Code deduplication is always good thing. Problem is that it's a lot of work to kickstart it. Because of that there are tons of duplicated code - especially for stm32, stm32wl5 and stm32wb. They are mostly the same, but are still duplicated. > > 4. How should I test the peripherals? I don't have all the LCD displays and > the other accessories supported by RP2040 port. Should I: > > a. keep the peripherals code for LCD, etc and hope that it will work > (explain in the documentation that it is not tested) > b. just add the minimum code without those peripherals support > c. buy the missing stuff or find other people to test it before I open the > PR Best is C of course :) but noone will expect from you to buy stuff to write the drivers - you do it only if you want to support project using not only your time but also money. So go B. It's better to not have things than have them half cooked in buggy state (I'm looking at you zephyr). -- .-----.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: RP2350 port part 2
On 2024-08-29 11:57:49, Marco Casaroli wrote: > > > 4. How should I test the peripherals? I don't have all the LCD displays > > and > > > the other accessories supported by RP2040 port. Should I: > > > > > > a. keep the peripherals code for LCD, etc and hope that it will work > > > (explain in the documentation that it is not tested) > > > b. just add the minimum code without those peripherals support > > > c. buy the missing stuff or find other people to test it before I open > > the > > > PR > > Best is C of course :) but noone will expect from you to buy stuff to write > > the drivers - you do it only if you want to support project using not only > > your time but also money. So go B. It's better to not have things than have > > them half cooked in buggy state (I'm looking at you zephyr). > > > > I will remove the code for stuff I cannot test right now. Not sure if full removal is good approach here. You did put some work into it. It would be shame to waste it. I think I would just go on and create separate pull request for them. You can also semi test things with logic analyzer. SPI can be tested that way. With SPI you can also connect MOSI to MISO and test communication that way. Once you confirm driver with bridging or logic analyzer you can create driver marked as EXPERIMENTAL. This will be a good indication that driver is somewhat working, but noone should expect production quality code in there. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: NuttX "gadget": resolve its host name via CDC/NCM connection
On 2024-10-08 20:56:00, Tim Hardisty wrote: > My intention is to implement a simple web server on the device so as to be > able to plug in to it via usb, go to a browser, and go to “http://gadget” > rather than “http://10.0.0.10” (for example). > > This is DNS…but my embedded networking knowledge is limited and I am not > sure what NuttX tools/daemons/examples/whatever I need to use for this? > > I don’t think a hosts file on the gadget is right, as the PC can’t use > that to match hostname to IP (and editing a hosts file on the PC is not an > option in this case). So probably the gadget needs to also be a DNS > server? But I can’t find much information on how to use the NuttX > implementation of this. > > Have I got that right or am I missing something? The thing you want to do, while possible is not really feasable. Yes, you must host DNS server on nuttx. I don't think there is anything ready to go, embedded devices usually do not act as a DNS. Then you would have to push DNS server to the host via DHCP. Problem is, that now you will overwrite DNS address on your host pc and you won't be able to resolve anything else other than what your nuttx 'gadget' device can. You could forward requests to external DNS, but that again requires nuttx to have internet. So DHCP/DNS on nuttx is not really good option. Having it reversed (DHCP/DNS on host pc) could probably solve the problem with some upnp magic. But that will require user to have upnp or some kind of zeroconf enabled on host pc as well. To my knowledge it's not possible to do what you want in portable manner. You can try some hacks, but the will not work for anyone - hence I would not recommend them. I have never ever met a embedded device that would do what you describe. It's always via IP address. So do what others do, and allow access via IP address only. That's the only portable way that I know of. -- .-----.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: Change time_t to signed type
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 | `--^--^--^-' signature.asc Description: PGP signature
Re: Questions about STM32 support/programming
On 2024-09-26 21:58:38, Matteo Golin wrote: > Hello all, > We figured we should check here first if anyone who had > experimented with STM32 chips knows offhand whether or not it's > possible to program over a USB interface, how to do it with the > NuttX build environment, or if it requires additional hardware. Hi, you should be able to flash and debug board via onboard stlink. All nucleos should have built-in stlink I think. So just connect nucleo via usb and check in lsusb if you have any stlink device. It should be visible like "STMicroelectronics STLINK-V3" I flash my boards with openocd: openocd -f interface/stlink.cfg -f target/stm32f3x.cfg -c 'program nuttx.bin 0x0800' You will need to change your target, there is target/stm32f7x.cfg and target/stm32h7x.cfg already in the openocd. I am not sure if start of flash is 0x0800 on f7 and h7, but I suppose it should be. This command will leave openocd opened with gdb server so you can start debugging it anytime you want with: arm-none-eabi-gdb nuttx "target remote 127.0.0.1:" -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: Questions about STM32 support/programming
On 2024-09-27 09:14:33, Nathan Hartman wrote: > I just had an idea that it would be neat to write a utility, which could > live under 'tools' (to be run on a developer machine) that would analyze > the current configuration and automatically generate the correct openocd > and gdb incantations. I haven't thought this through yet, so I don't know > if it's feasible and what might be involved, but I thought I'd mention it > here as food for thought. I don't like zephyr, but 'west flash' is a good thing they did. I proposed this in the past when there was a discussion about how to make nuttx more popular. You could create phony target 'make flash', which could propagate it to make.def in board directory. I think something like that is mandatory if nuttx should be more popular. To be more popular it must get more user friendly. Not everyone wants to fight with bootloader/flashing. They just want to realize their idea - and not learn build system and flashing tools. I also hate to say that - but if you are commited to cmake (ugh) it might be good idea to drop raw Makefile support. This just makes things more complicated for both maintaners and end user - nuttx is giving kinda useless choice for the end user here I think ;) > Off the top of my head I don't remember whether the STMF7 family has a ROM > bootloader. If it does, you probably need to pay attention to a BOOT pin on > the chip. Nothing wrong in having 2 bootloaders. On chip bootloaders are often very limited and are more suited for recovery than final product usage. Custom bootloader can be relatively easily configure to - for example - fetch image from tftp and boot it - awesome for development. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: milk-V DUO s
On 2024-09-18 12:41:13, Alan C. Assis wrote: > This aic8800 driver is GPL license, we cannot use it. > Probably they released it as GPL to be used on Linux kernel. In theory it can be used in nuttx. But including it (enabling for compilation) will basically upgrade whole license for every file to GPL. This is not really a concert for nuttx but for end developers using RTOS. If they enable this single library, they will have to ship source code for their WHOLE project with their product. Drivers like could simply tick "select GPL" in kconfig, and a notification could be printed before compilation that this is no GPL licensed code. I don't know how is Apache foundation feeling about things like that, but GPL does not care. It's not ideal. But it's not a closed door either. -- .-.---.------.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: Problems with STM32F7 and STM32H7 boards
On 2024-10-01 10:52:18, Roberto Bucher wrote:
> Thanks Michal
>
> changing the arm-gcc version can probably change the size of the generated
> code.
No, stack size is per thread, and has nothing to do with code size.
Stack size refers to automatic storage variables like
int main(void) {
int a;
char c[32];
}
This will take about 36 bytes of stack memory. Each nested function also uses
some stack space for arguments, return pointers etc.
I don't know how you generate your app, if it's automatic from kconfig+makefile
then stacksize is determined by STACKSIZE makefile variable, which is usually
set by some Kconfig setting with similar name.
--
.-.---.--.-.
| 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 |
`--^--^--^-'
signature.asc
Description: PGP signature
Re: Problems with STM32F7 and STM32H7 boards
On 2024-10-01 09:38:56, Roberto Bucher wrote: > By launching "main" I have this error: > > nsh> main > ERROR: Failed to wdump_assert_info: Current Version: NuttX 12.6.0-RC1 > d4968905c5 Oct 1 2024 08:53:59 arm > dump_assert_info: Assertion failed panic: at file: :0 task: 0x8000361 > up_dump_register: R0: R1: 38005bf0 R2: 1810 R3: 1800 > up_dump_register: R4: 080002e9 R5: R6: FP: > up_dump_register: R8: SB: SL: R11: > up_dump_register: IP: SP: 38006318 LR: 08002807 PC: 0800a692 > up_dump_register: xPSR: 2100 PRIMASK: CONTROL: > up_dump_register: EXC_RETURN: ffe9 > dump_stack: User Stack: > dump_stack: base: 0x38005cc0 > dump_stack: size: 2024 > dump_stack: sp: 0x38006318 > Any ideas? Is this "main" your own app? First thing I would check is stack size for that thread. Also enable stack colorization, stack canaries and stack usage statistics. Overflowing stack on embedded is number 1 in amount of errors I've seen during early development. Sharing your main code might also be helpful in debuging it. -- .-----.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: UART based peripheral driver
On 2024-09-30 12:51:06, Matteo Golin wrote:
> Hello,
> I did find a function called `stm32_get_uart()` which returns the UART
> device; this is more what I am looking for. It doesn't seem like most
> other platforms implement a similar function though, and I'm not sure if
> it is good design to require that an architecture first implement
> something similar before being able to use this driver. I don't want to
> introduce this pattern to NuttX without first checking for other
> suggestions.
Whatever Greg said, plus from me: your lora chip is mcu agnostic, so do
not use anything from the arch/ to implement the driver. There should be
absolutely zero arch related code in that driver.
This will allow driver to be used with any MCU that has serial interface.
Also design your rn2483_init() funtion driver to accept struct to initialized
serial driver. It's not your drivers responsibility to initialize serial
device, it should be provided to you by code in boards/ directory. So
in pseudocode it would look like this
stm32_init_rn2483() {
struct serial *serial;
/* get serial device specific to the board, one board will use USART1
* other might user USART2. Decision which uart to use depends on board
* hardware wiring and may be different even for the very same mcu */
serial = stm32_get_serial_for_lora();
/* initialize rn2483 lora driver and give it handle to the serial device,
* rn2483 driver can immediately use it from on to initialize the rn2483
* chip driver */
rn2483_init(serial);
}
--
.-.---.--.-.
| 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 |
`--^--^--^-'
signature.asc
Description: PGP signature
Re: Problems with STM32F7 and STM32H7 boards
On 2024-10-03 14:16:40, Roberto Bucher wrote: > _assert: Assertion failed panic: at file: armv7-m/arm_hardfault.c:175 task: > 0x80002b9 > > and this is related to the call of the function > > exit(1); > > in my code, for example if a device is not defined. The call to this exit(1) > function leads to this assertion error. > Basically, what I have to do is only to stop my (generated) application and > I think that it was ok in the past... > > Any idea how to solve this? I don't understand? What do you wanna solve? Hardfault? Well, then don't call exit() function? I mean, if program cannot continue just add proper log before doing call to exit() so next person does not have to think hard what is going on. Better yet - if it's possible to do, use static_assert()/COMPILE_TIME_ASSERT() to issue error during compilation time that something is not defined. -- .-.-------.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: Problems with STM32F7 and STM32H7 boards
On 2024-10-03 17:02:09, Roberto Bucher wrote: > I developed a python application called "pysimCoder" similar to XCos and > Simulink, which is able to generate control code for different targets > (Linux, Linux RT, Raspberry PI, NuttX and others). We have about 175 blocks > for the different targets already defined for inputs, outputs, functions, > sensors, actuators etc. > > The into 3 functions, called from a main: > > initialization, termination and interrupt service routine > > The last one is called by a temporized thread. > > If the initialization fails, the program must stop: till now (also in > NuttX), this is realized by simply call the "exit(1)" function in the > initialization procedure! Now (new?) in NuttX, when we call the "exit(1)" > function we get the "Assertion failed panic" message, and no more the stop > of the running control program, instead of return into the nsh application. > > Of course, it is possible to exit from the main thread Using return) after > controlling if the initialization function of a block is failed: but to > implement this we, have to change the code of all the 175 blocks... Ok I see. So you expected exit() to work same as on, say, Linux. So that app just exits back to the shell. According to function documentation is should work like that > The exit() function causes normal process termination and the > least significant byte of status (i.e., status & 0xFF) is > returned to the parent (see wait(2)). Don't know why it asserts, maybe you miss some config? Your best bet to fix it is to put breakpoint at your exit() function, and step through the code. Nuttx is exceptionally well documented in its C files, you will have no problems following it. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: Change time_t to signed type
On 2024-11-06 10:01:55, Nathan Hartman wrote: > I am +1 for a Kconfig. > > * or just make the default 64-bit on ALL systems, and if you are > trimming resources, you can make a judgment call whether to reduce it > to 32-bit I would say this. I believe defaults should be what works for majority of cases. Things to work is more important for things to be quick. People of different experience and knowledge uses this RTOS. A lot of people won't even notice performance hit from 64bit time, but they will surely notice weird time bugs. Having code we know is going to crap out in the near future is kinda strange design choice. I think you could have ignored it when there was 50 years left, but this will happen in 14 years which is not that far for embedded systems that can work for decades. -- .-.---.--.-----. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: Explanation request about a the merging of an unacceptable pull request
On 2025-02-03 22:45:29, Xiang Xiao wrote: > The ai bot is a soft suggestion, not a rule from Lup introduces it > initially. > Many PR already contain the useful information, like these: > https://github.com/apache/nuttx/pull/15749 > https://github.com/apache/nuttx/pull/15728 > But ai bot still complain the information isn't enough. > Even https://github.com/apache/nuttx/pull/15437 already contains the enough > information to explain why this change is made. Yep, especially this section of PR perfectly explains steps performed to not break anything: > Testing > > Update this section with details on how did you verify the change, > what Host was used for build (OS, CPU, compiler, ..), what Target was > used for verification (arch, board:config, ..), etc. Providing build > and runtime logs from before and after change is highly appreciated. That PR touched WHOLE cpu family, and yet not a single test was performed on real hardware it seems. -- .-.---.------.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: app/os sync creates many problems
On 2025-01-31 13:48:32, Tomek CEDRO wrote: > On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet > wrote: > > Of course I also tried with the commit before that one, and it didnt > > work either. > > Sebastien, did you try the release packages? Does the problem occur in > the release packages? > > Upstream master is for development purposes, things may get broken for > a while, I would never put my product on a master branch. This is offloading responsibility to end user. Sebastian is right here. Either apps are separated properly so that even 1 year old apps repo will work with current HEAD of rtos, or nuttx should have sync mechanism like submodules (don't go there) or tool like Zephyr's west to sync it (or it can also be done with make/cmake). Did you ever try to bisect problem in nuttx? Constant failures in apps and you have to manually guess which commit is going to at least compile - and then you still cannot be 100% sure soft does/doesn't work as indended. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: app/os sync creates many problems
On 2025-01-31 16:20:51, Tomek CEDRO wrote: > On Fri, Jan 31, 2025 at 3:35 PM wrote: > > On 2025-01-31 13:48:32, Tomek CEDRO wrote: > > > On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet > > > wrote: > > > > Of course I also tried with the commit before that one, and it didnt > > > > work either. > > > > > > Sebastien, did you try the release packages? Does the problem occur in > > > the release packages? > > > > > > Upstream master is for development purposes, things may get broken for > > > a while, I would never put my product on a master branch. > > This is offloading responsibility to end user. Sebastian is right here. > > Either apps are separated properly so that even 1 year old apps repo will > > work > > with current HEAD of rtos, or nuttx should have sync mechanism like > > submodules > > (don't go there) or tool like Zephyr's west to sync it (or it can also be > > done with make/cmake). > > > > Did you ever try to bisect problem in nuttx? Constant failures in apps and > > you > > have to manually guess which commit is going to at least compile - and then > > you > > still cannot be 100% sure soft does/doesn't work as indended. > > Hmm, I get it. I saw that too. I thought it should be always in sync. > > I saw changes in either nuttx or nuttx-apps that depends on each > other. Not sure if that would allow apps to build / work on one year > old rtos code. > > So what are your solution propositions? There are 2 long term solution I see. 1) lower effort one - keep commit hash of apps in some file. Either check hash before doing `make all` or add new makefile command like `make appsync`. Either way, file .app-hash should always contain working app commit hash. app hash can also be hold as a Kconfig field. This will probably be enough - especially for bisecting. 2) Rewrite build system for apps. Use only absolute minimum and very stable API in rtos/apps. Really, apps should not have the need to know much about RTOS, few header files should be enough. When you build app for Linux you don't ingegrate with kernel source in any way - just use some header files provided by os/libc. Maybe there is 3) option I didn't thing about. > Usually OS has something called API and apps must adhere to that API. > If breaking change is introduced API number is bumped and so apps > needs an update. API/ABI to OS should not break apps, like ever. You can look up what Torvalds thinks about that. Internal API change is fine. But try to introduce ABI change for Apps, and be a part of immortalized in the internet as person Linus killed with words ;) > We should discuss and vote this kind of design decision and put inside > CONTRIBUTING and documentation f anything changes. > > Also I welcome everyone to help in PR review if changes are impacting > you, catch them first before merge :-) I'd love to, but can't get any company to choose Nuttx over Zephyr ^^ And privately I am currently doing projects that don't really involve RTOS at all. So I am kinda out of the loop these days. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: app/os sync creates many problems
On 2025-01-31 17:34:48, raiden00pl wrote: > How do you want to maintain compatibility between nuttx-apps and > nuttx while both are active development projects, and what's more > one of them is optional? It's not possible. Same way as app/kernel compatibility is maintained in othes Unices like Linux or BSD. > It would be possible if we assumed that the API in NuttX is perfect > and will not require changes, which is not true. There are many custom > solutions in NuttX that require improvements and these improvements > will break compatibility. There are many custom interfaces that need > improvement, such as PWM or sensors, and these changes will > definitely break apps. No, just be super careful designing API to "userspace" and once commited it stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as well. That's why we still have "creat" instead of "create". Or we have 3 poll APIs in Linux (select/poll/epoll). You really want to change API, you build another one, and mark old one as deprecated, but you don't delete it. That would be ok if Nuttx was <1.0.0, version, but it's >=1.0.0 so it should care about API/ABI. Especially that it does not have to come up with API and just use what Posix been using for decades now. > On the other hand, any standardized interface like POSIX must be stable, > which is obvious. But POSIX doesn't define everything, especially when > it comes to embedded systems. So you carefully define it, keep it as EXPERIMENTAL for some time, which allows for breaking changes, but once API is marked as stable - it is set in stone. Period. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: GSoC 2025
Hi, there is still a possible work to do though. We could try to design an alternative algorithm that would not need three partitions. There are advantages of the current design (fast update even for big images, low flash wear, you always have a recovery present etc.), but it is mostly intended for devices with the external flash memory. So an alternative algorithm for devices without the external flash (or with small flash that can't afford to put two partitions there) could be interesting. We discussed this idea in Elektroline some months ago if I remember correctly, but it has not been a priority ever since that. And I think MCUboot also has something similar, so it should be possible. Or there is no encryption support for the bootloader now. Best regards, Michal On 04. 02. 25 13:34, Alan C. Assis wrote: Hi Tomek, I think the support already exist: https://nuttx.apache.org/docs/latest/applications/boot/nxboot/index.html BR, Alan On Tue, Feb 4, 2025 at 3:28 AM Tomek CEDRO wrote: How about to try out NuttX as bootloader for other OS as the idea for GSoC 2025? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: NuttX Code Quality Improvement 2025Q1
Hi Tomek, I think most of the points make sense, just few notes to some of them. > * Number of required code reviews should be increased from 2 to 4. > This will ensure cross-checks and filter out faulty changes. Perhaps I would limit this to larger commits only (and all affecting Build / Kernel / common arch code of course). GitHub bot tells you the size of the pull request, so we can draw some line according to that. And maybe it could also automatically set the mandatory number of reviewers. This way simple changes/fixes/additions to BSPs or MCU drivers would be handled faster. > * If change touches Build / Kernel / Architecture it must be presented > and discussed on the mailing list with the community first. PR may be > created with clear indication it is for discussion and marked as draft > not to be "accidentally merged". By Architecture, do you mean common architecture code or even MCU specific code? I am not sure if describing every change to a single MCU on a mailing list is beneficial, I am afraid it will just flood the list and no one will read it. GitHub issues seem more suitable for this. > Also it will be nice to have monthly online meetings just to talk > things over and stay connected and synchronized. It should bring > community closer together :-) Yes! We have to find a proper channel for this though. I think there were efforts to have meetings on our Discord channel, but many people don't like the platform (for understandable reasons) so it didn't last for long. Best regards, Michal On 2/6/25 04:45, Tomek CEDRO wrote: > Hello world :-) > > We have long discussions over the last months NuttX code quality and > self-compatibility degradation. I think open discussion in this area > as for 2025Q1 can be constructive. Please join the discussion :-) > > After we have a good understanding and agreement on selected points we > should update Contributing Guidelines both for developers and > reviewers. > > * Each PR _must_ adhere to requirements presented in Contributing > Guidelines or be auto-rejected, that is present what this change does, > why it is necessary, what if fixes and how, what is the impact, how it > was tested (build and runtime test logs mandatory!!). > * Number of required code reviews should be increased from 2 to 4. > This will ensure cross-checks and filter out faulty changes. > * Reviews should come from independent organizations. > * Single company commit, review, merge is not allowed. > * Self commited code merge is not allowed. > * Each commit message must adhere to above (i.e. mandatory and > self-explanatory topic and body with description, both topic and > description are mandatory, may be simple single sentence or bullet > points) or it will be auto-rejected. Simple changes require simple > description, complex changes more, potentially breaking changes or big > changes require solid proof nothing gets broken. > * Both PR description _and_ commit messages are important especially > in case of problems. If something gets broken we will be able to > understand what was the goal of change.. or just by reading the git > log to know what changed why and how. Verification logs may be part of > PR only as these will be too long for git log. > * If change touches Build / Kernel / Architecture it must be presented > and discussed on the mailing list with the community first. PR may be > created with clear indication it is for discussion and marked as draft > not to be "accidentally merged". > * If change touches Build / Kernel / Architecture then build and > runtime test (i.e. apps/ostest) logs from developer working on a real > world hardware are mandatory! > * If change touches Build / Kernel / Architecture build and qemu is > not enough as it does not catch all problems visible on real world > hardware as we saw recently. > * We should implement zero trust approach to user provided testing. > * It is commit author to provide real world hardware build and runtime > logs that change does not break stuff. > > Also it will be nice to have monthly online meetings just to talk > things over and stay connected and synchronized. It should bring > community closer together :-) > > There were also other nice ideas, please join the discussion :-) > > Tomek >
Re: NuttX Code Quality Improvement 2025Q1
On 2025-02-06 18:48:18, Tomek CEDRO wrote: > On Thu, Feb 6, 2025 at 4:51 PM wrote: > > On 2025-02-06 08:43:34, Michal Lenc wrote: > > > > Also it will be nice to have monthly online meetings just to talk > > > > things over and stay connected and synchronized. It should bring > > > > community closer together :-) > > > > > > Yes! We have to find a proper channel for this though. I think there > > > were efforts to have meetings on our Discord channel, but many people > > > don't like the platform (for understandable reasons) so it didn't last > > > for long. > > Well, there is always IRC. And folks from libera.chat is very friendly. > > It's a goto server for basically all projects that want to have an IRC > > channel now. > > Yes I still use IRC sometimes.. but its better to see each other live > talks and make jokes :-) > > What is wrong with Discord? I thought this is kind of modern IRC with > audio and videocalls.. it has chat with rooms just like IRC :-) One word answer: electron. And mandatory link because IRC was mentioned: https://xkcd.com/1254/ -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: NuttX Code Quality Improvement 2025Q1
On 2025-02-06 19:47:28, michal.lyszc...@bofc.pl wrote: > On 2025-02-06 18:48:18, Tomek CEDRO wrote: > > On Thu, Feb 6, 2025 at 4:51 PM wrote: > > > On 2025-02-06 08:43:34, Michal Lenc wrote: > > > > > Also it will be nice to have monthly online meetings just to talk > > > > > things over and stay connected and synchronized. It should bring > > > > > community closer together :-) > > > > > > > > Yes! We have to find a proper channel for this though. I think there > > > > were efforts to have meetings on our Discord channel, but many people > > > > don't like the platform (for understandable reasons) so it didn't last > > > > for long. > > > Well, there is always IRC. And folks from libera.chat is very friendly. > > > It's a goto server for basically all projects that want to have an IRC > > > channel now. > > > > Yes I still use IRC sometimes.. but its better to see each other live > > talks and make jokes :-) > > > > What is wrong with Discord? I thought this is kind of modern IRC with > > audio and videocalls.. it has chat with rooms just like IRC :-) > One word answer: electron. > > And mandatory link because IRC was mentioned: https://xkcd.com/1254/ I made a mistake, it was supposed to be this one :P https://xkcd.com/1782/ -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: [DRUNX] Distributed Runtime and bUild for NuttX
On 2025-02-06 16:02:18, Matteo Golin wrote: > I've got: > - Raspberry Pi Pico > - Raspberry Pi Pico W > - XIAO RP2040 > - XIAO SAMD21 > - Raspberry Pi 4B > > And would also be willing to help test, provided it's easy enough for me to > automate. Just looked into my lost and forgotten drawer. As of today I have: - nucleo wl55jc1 - nucleo f091rc - nucleo f303re - nucleo f429zi - stm32h735g - stm32butterfly2 (stm32f107) - mimxrt1050-evkb - mimxrt1060-evkb - mimxrt1062(teensy 4.2) - rpi pico - samc21 xplained Most of them have on board debugger. If not I also have few swd/jtag debuggers that I am not really using anymore. If you make this project so I can just put rasbian + your script to init.d I can donate these, rpi4, some USB hub and some space in my lab for testing. Scripts must not be running as root. I could also create some DMZ for boards with networking capability to test those as well. -- .-.---.------.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: NuttX Code Quality Improvement 2025Q1
On 2025-02-06 08:43:34, Michal Lenc wrote: > > Also it will be nice to have monthly online meetings just to talk > > things over and stay connected and synchronized. It should bring > > community closer together :-) > > Yes! We have to find a proper channel for this though. I think there > were efforts to have meetings on our Discord channel, but many people > don't like the platform (for understandable reasons) so it didn't last > for long. Well, there is always IRC. And folks from libera.chat is very friendly. It's a goto server for basically all projects that want to have an IRC channel now. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: [VOTE] NuttX Contributing Guidelines update 202502.
Hi, 1: +1 2: +1 3: +1 4: +1 5: +1 6: +1 7: +1 8: +1 9: +1 10: 0 these are sometimes necessary 11: +1 12: +1 13: +1 14: -1 I would still apply it only for bigger changes 15: +1 16: +1 17: +1 Thanks for organizing the vote! Michal On 2/11/25 00:37, Tomek CEDRO wrote: > Hello world :-) > > As discussed extensively in various mailing list threads we have > gathered all additional ideas for Contributing Guidelines update that > should improve NuttX Code Quality and self-compatibility / long term > maintenance. > > Lets vote what we have. If anything is missing then lets talk about > this in "NuttX Code Quality Improvement 2025Q1" thread and add to vote > here the final form. > > Each proposal is given number, please vote +1, 0, or -1 in reply for > every number to vote for, neutral, or against proposed update. > Comments are welcome too :-) > > 1. In Contributing Guidelines we are adding additional section for > Reviewers in order to provide complementary set of rules that should > filter out breaking code as much as possible also on our side. > > 2. Each PR (including git commits) _must_ adhere to requirements > presented in Contributing Guidelines or will be auto-rejected until > fixed / updated. > > 3. Git commit messages are as important as PR descriptions. These > provide in-code descriptions of each change and are git interface > independent. > > 4. Proper description of change is mandatory. Description must contain > explanation on what proposed change do, why it is necessary, what if > fixes, and how things are changed / fixed / updated, what is the > impact (build / runtime / api / what area), how it was tested. Local > code build and real world hardware runtime test logs must be provided > where mandatory. Description can be single..several sentences long or > bullet points but enough for anyone to understand change goals and > details. Usually it will look similar for PR and git commit message. > > 5. Proper description in PR is mandatory, or change is auto-rejected > until fixed / updated. Build and real world hardware runtime logs are > mandatory. > > 6. Proper description in Git commit message is mandatory, or change is > rejected until fixed / updates. Build and runtime logs are optional > here if these are too long and already provided in PR. > > 7. Each git commit message must consist of topic, description, and > signature, which are mandatory, or change is auto-rejected until fixed > / updated. Topic consists of functional prefix, ":" mark, and short > self-explanatory context. Description is separated from topic with a > single blank line. Example already presented in Contributing > Guidelines. > > 8. Changes must come with with documentation update where applicable. > If change presents new functionality a documentation must be provided > in the same PR (not in future). If change requires documentation > update it must be contained in the same PR (not in future). Successful > documentation build log shortcut is welcome. > > 9. We implement zero trust approach to user provided testing. It is > the commit author duty to provide real world hardware build and > runtime logs that must prove change does not break stuff for others. > > 10. Breaking changes are not welcome. This is anything that alters > Build / Kernel / Architecture / API, alters both nuttx and nuttx-apps > repo at the same time, breaks build/runtime/api for single or many > boards/architectures/applications, breaks self-compatibility, breaks > build/runtime compatibility with existing release code (packages) both > for nuttx and nuttx-apps, etc. > > 11. We respect long term maintenance and self-compatibility is our > ultimate goal. Alternative solutions and non-invasive approaches are > preferred that offers user a choice and compatibility. Breaking > changes are avoided, and planned towards next major release. > > 12. Breaking changes _must_ be discussed prior introduction on the > dev@ mailing list. PR may be created with clear indication it is for > discussion and marked as draft not to be "accidentally merged". > > 13. Breaking changes are special case where build and > runtime test logs (i.e. apps/ostest) from more than one different > architecture is mandatory. QEmu tests does not count here as it passed > breaking change that did not work on a real hardware. > > 14. Number of minimum required code review votes should be increased > from 2 to 4. This will ensure cross-checks and filter out faulty > changes. > > 15. Counting review votes should come from independent organizations. > There may be more than one review from a single organization, but > these will count as one vote. > > 16. Single company commit, review, merge is not allowed. > > 17. Self committed code merge is not allowed. > > Thank you :-) > Tomek >
Re: [VOTE] NuttX Contributing Guidelines update 202502.
> 18. Pull Requests should be as small as possible and focused on only > one functional change. Different functional changes should be provided > in separate Pull Requests. Remember that breaking changes are not > welcome. Pull Requests must not break overall build, runtime, and > compatibility, especially for other components. When changes must be > bundled together in order to maintain functionality and > self-compatibility, exception can be made, and this must be clearly > stated there is no other way. 0: Does this apply to the documentation as well (discussed in a different thread for LTS)? I prefer to put the docs in one PR instead of creating the second one. We have a documentation in a single repository (compared to other projects like RTEMS for example), so let's take the advantage of it. Otherwise we can split the code and documentation into two repositories. But that's harder to maintain. Also another example is the implementing a new peripheral for some MCU. This implementation SHOULD come with another commit that adds the support for it to BSP, otherwise the CI jobs for the peripheral are useless, the new code is not build at all. > 19. "Lazy consensus" is a situation where PR is auto-merged into the > upstream when not enough reviews are done in predefined time (i.e. > there are no minimum required positive reviews within two weeks time). > PR should initially be treated according the general rules (4 > independent reviewers); After a week without enough reviewers, a call > should be made on the > mailing list, explaining why the PR can't be split into smaller PRs; > After two weeks without any reviewers, we could merge if the above > conditions are met and we have at least one independent reviewer. This > may solve situation when we don't have enough people to review it (or > we are not interested in that). It prevents people from forking the > project just to be able to develop their stuff: *we* *really would not > like that*. The PR's author is still responsible for fixing some > bugs if found in the future. -1 in case we don't require 4 reviewers for every PR, but only for major and potentially breaking ones, otherwise +1. Michal On 2/12/25 11:37, Tomek CEDRO wrote: > Lets add these two points to vote that came out of the discussion and > see the reaction. > > This vote is to see what subjects we do agree already and what needs > update / clarification :-) Where are all +1 we can implement already, > where is at least one -1 that needs fix, where is 0 we may clarify > some information with the feedback provided :-) > > > 18. Pull Requests should be as small as possible and focused on only > one functional change. Different functional changes should be provided > in separate Pull Requests. Remember that breaking changes are not > welcome. Pull Requests must not break overall build, runtime, and > compatibility, especially for other components. When changes must be > bundled together in order to maintain functionality and > self-compatibility, exception can be made, and this must be clearly > stated there is no other way. > > > 19. "Lazy consensus" is a situation where PR is auto-merged into the > upstream when not enough reviews are done in predefined time (i.e. > there are no minimum required positive reviews within two weeks time). > PR should initially be treated according the general rules (4 > independent reviewers); After a week without enough reviewers, a call > should be made on the > mailing list, explaining why the PR can't be split into smaller PRs; > After two weeks without any reviewers, we could merge if the above > conditions are met and we have at least one independent reviewer. This > may solve situation when we don't have enough people to review it (or > we are not interested in that). It prevents people from forking the > project just to be able to develop their stuff: *we* *really would not > like that*. The PR's author is still responsible for fixing some > bugs if found in the future. > >
Re: app/os sync creates many problems
On 2025-01-31 21:14:23, raiden00pl wrote: > > No, just be super careful designing API to "userspace" and once commited > it > stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as > well. > That's why we still have "creat" instead of "create". Or we have 3 poll > APIs in > Linux (select/poll/epoll). You really want to change API, you build another > one, > and mark old one as deprecated, but you don't delete it. That would be ok if > Nuttx was <1.0.0, version, but it's >=1.0.0 so it should care about API/ABI. > Especially that it does not have to come up with API and just use what Posix > been using for decades now. > > I can't agree with this. Stockpiling legacy code degrades code quality, the > code > is harder to maintain and is harder to use by users. > I think there are cases where it's justified to break compatibility. > Especially if > the breaking changes for the users are easy to fix and detect, and the > interface > that is being modified has obvious flaws. And of course, everything should > be well documented. That is not excuse. Maintaining old API is not hard. Usually it's just a simple call to new API, which will not require further maintenence. You can even kick it to separate file so it does not break code aesthetics ;) Inside nuttx repo you can break all the APIs you want. But outside of it this should not happen. NuttX it not crazy small project used by handful of people anymore. By publishing API now, you are making a contract with other developers. Break too many of such contracts and you have situation like with Sebastian. At least he was kind enough to share his thoughts with you so you can act. Probably many more people just quietly quit. Take expamles from other projects. I can update my openbsd with 0 issues. And if some breaking changes in configs are introduced you always get great documentation what has changed and how to prepare for that change. Creating something new is always fun and is easy. But you have to maintain it later thru the updates. There is a reason why I am not getting even close to ruby. I'd rather use clunky PHP which has some problems on its own, but it never broke my software/installation with updates, while with ruby based apps there was always struggle. Change just for the sake of change never worked out well for anyone. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: Request for being member
On 2024-12-12 09:09:43, Kriti. D wrote: > Hello, > I am new to Nuttx and wanted to learn about it more. This email was found > in response to my trying to join the Nuttx community. Is this the right > place to subscribe? > > if it is i would like to request to join the community. Thank you so much You don't really "join" an open source community. You just start contributing to it. Be that code, documentation, helping others via this mailing list or simply testing code. After some time you get recognition, more respect, people are starting to depend on you. Then you may get some more responsibility (if you wish) like accepting pull requests. So just go, write code, fix bugs, improve documentation in any way (be that even a typo) and have fun while doing so ;) That's all there is to it really. Also there is no right or wrong amount of contribution. Any contribution is appreciated. -- .-.---.------.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: Kconfig: select vs depends on
On 2024-12-17 13:27:48, Tomek CEDRO wrote: > Hello world :-) > > Recent PR #2893 [1] proposed using "select" statement for "PIPES" as > dependency of "LIBUV" option. There is a preference to use "depends > on" in that case [2]. What are your preferences and experiences in > this area? Is there a policy / preference in this area for NuttX? :-) > > What are dangers of using "select"? Why "depends on" is preferred? Select gonna fail for "nested dependencies". CONFIG_A depends on CONFIG_B which depends on CONFIG_C If you select A, A will select B, but it will not select C automatically, A will have to have both "select B" and "select C". This can lead to bugs I - personally - prefer depends for visible (user selectable) entries. While select can be used to select invisible entries like | config CHIP_X | bool "select chip X" | select HAVE_UART | select HAVE_SPI If you don't want for user to miss on some features I also include reversed config like: | comment "psmq requires SYSTEM_EMBEDLOG and !DISABLE_MQUEUE" | depends on DISABLE_MQUEUE || !SYSTEM_EMBEDLOG | | menuconfig SYSTEM_PSMQ | bool "psmq" | default n | depends on !DISABLE_MQUEUE && SYSTEM_EMBEDLOG In this case if you have enabled mqueue and embedlog you will see selectable | [ ] psmq otherwise you will see comment | --- psmq requires SYSTEM_EMBEDLOG and !DISABLE_MQUEUE --- This has number of perks: - user see all potential features he can choose from, regardless of what is currently selected - end user will immediatelly and explicitly see what gets pulled for a config - no chance to break with nested dependencies - if embedlog suddenly starts to require new option, only embedlog kconfig will have to be modified (with new depends on option) - no illegal configurations are possible with depends (while it is possible with select) So, rule of thumb - use select only for non-visible (non-selectable anywhere) symbols - use depends everywhere else. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: GSoC 2025
Hello all, I would like to propose the PWM upper-layer driver refactorization as a possible GSoC topic for this year. The idea has already been discussed in a GitHub issue <https://github.com/apache/nuttx/issues/12381> and some solutions and steps have been proposed. The current PWM driver has a bit messy pwm_info_s structure used for setting frequency, duty cycle and other characteristics. It was initially designed for a single PWM channel drivers, but the added support for multiple channels made it more complicated. Now we basically have a different API based on CONFIG_PWM_MULTICHAN option. Additionally, it has some setbacks. One can't configure a different frequency for different channels, which is a feature supported by some MCUs, both duty cycle and frequency has to be recalculated to fit PWM range (16 bit usually, but may be different), there is a big overhead if just some characteristics are set and so on. The driver also combines standard PWM and pulsecount ability, which have different purposes and could be separated into two drivers, as Mateusz suggested. The change to the driver will definitely be a breaking change API-wise, but so far we agreed there are more benefits from simplifying it and doing it right. The new structure proposed by Pavel Píša also has less overhead if one PWM is configured as a multi-channel and other with just one channel and some other benefits. In general, this could be a nice GSoC project. The API redesign should not require much coding, but has to be discussed thoroughly so we do it right. The subsequent changes to low level drivers would probably take a significant amount of time as well, because we would have to test these drivers. I could help guiding the project if we find a student to apply for it (I am not sure if we'll have someone from CTU this year) and possibly provide tests on some hardware (samv7, imxrt, stm32...). Best regards, Michal On 15. 01. 25 23:40, Tomek CEDRO wrote: Google Summer of Code 2025 is coming, we already can and should register ideas for NuttX :-) https://community.apache.org/gsoc/
Re: trust in nuttx gone
On 2025-01-29 12:12:58, 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. 100% agree. Greg had good vision. Small and simple Posix RTOS. Things started to bloat uncontrollably after Apache had taken over. No wonder that Sebasian has problems with build system, when Nuttx has now 2 build system - for zero gain. Makefiles were working, they were also simple. Now we have 2 build systems, and CMake to this day does not support all apps. CMake should have been a replacement - not addition. Roadmap should also contain scope of project. Do you want to add support for rust/zig/python? Where is SDK? It's really hard for newbies to kickstart simplest hello world. Now it feel like mainters merge everything to not "discourage" people, or they merge what they personally like. With roadmap and scope there would be not issue with that. Someone pushes Rust thing? Roadmap says no - auto decline. Again - less is more. It's better to have less fature but well polished than have tons of half baked fatures that require hacks. Don't take Sebastian's message as personal attack. Yeah, he went ballistic there. But it's probablly because of years of frustrating moments. This should be treated as a waking call when such long-standing member decides to leave because project makes his life harder instead of easier. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: trust in nuttx gone
On 2025-01-28 11:23:26, Sebastien Lorquet wrote: > my trust in nuttx is now hard to maintain. > > Every day a DELUGE of commits (from xiaomi, this is a fact) is added to the > repository. > > I am struggling to understand what happens in this project. > > so many fixes are pushed, how is that even possible? this is a quicksand > project! Project gets more popular. This is both good and bad. More commits/fixes are good, but it also increases chances of something bad slipping thru. Especially that Nuttx does not have that many core developers that can really sit and review the code. And reviews take tons of time and requires lot of knowledge. > > > Also, how are such commits (not from xiaomi!) allowed? No description except > "uf2" ? Where is the adult in charge? > > https://github.com/apache/nuttx/commit/dac3f315a11cead82a5f630d4ae1c3eb45a80377 Commit is awful, true. But then again, you cherry picked commit that supports your thesis. > I am announcing that after that many years my company has started to develop > a minimal rtos to replace our usage of nuttx, because it is just not stable > enough to be usable for stable long term projects. > > There are too many changes, we are loosing money every time we need an > update. there is no way to maintain the use of a nuttx custom board and > project over several years. What changes are you talking about? Nuttx is Posix, so no "userspace" app should get broken by any change - if it does, then there a problem in Nuttx that should be reported and fixed. Merge conflicts in kernel? Push your improvements to mainline, problem will solve itself for the most part. > Having control of our code will be a better investment. That will obviously > be closed source. Which is, after all, a better way of control on our > products. Good luck with that. Every custom RTOS I worked with was an attrocious. FreeRTOS + Vendor HAL is not good pair. You will be in world of pain. I'd rather use Zephyr than making own semi baked RTOS. Let's not even start on topic when you are going to change MCU vendor (like stm to microchip). Seriously buddy, if not Nuttx, then save yourself some pain and go with Zephyr. > No amount of my involvement in the github triage is going to help, the case > is desperate. I just have no time, no energy, no motivation, no spoons left > to deal with this. it's a deluge of commits, let it be, but without me. > > the warning from the apache foundation that you use too many ci credits > should have been a warning to slow down and reflect on the project > direction. nothing has happened except making it even faster. > > I will also discourage people to use this project, I cannot in good > conscience recommend it to anyone, it would be a trap. Being salty hepls noone. Point out what bothers you. If commits are constantly messing up with your projects it's either your problem or Nuttx problem. These things should be reported so they can be acted upon. Either Nuttx will be fixed or you will be told how to properly maintain your code within Nuttx. It's true that Nuttx does no quite know where it wants to go and be right now. Introducing CMake without removing Makefiles where very bad decision - as you have to maintain two build systems now - which takes time from other more important things. Introducing Zig and Rust feels also like a fashion move. Rust feels like it's being shoved down everyone's throat. And Nuttx has more cleaning up to do before adding even more gimmicky stuff. It really does feel like Nuttx wants to do much more then it was intended to do. Also there is simply not enough manpower to maintain so many things. Less is more, more is less. -- .-.---.--.-. | 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 | `--^--^--^-' signature.asc Description: PGP signature
Re: GSoC 2025
Hi Tomek, I certainly won't have a capacity to apply as a student for this years GSoC, but I could participate as a mentor/consultant/whatever if someone chooses NXboot for his GSoC project. I am not sure if Stepan Pressl will have time for that in the summer, but he is currently working in that area on an updater application. Best regards, Michal On 20. 03. 25 13:01, Tomek CEDRO wrote: Thank you Pavel :-) We should then request registration for two Apache NuttX Mentors, please confirm? 1. Pavel Pisa, p...@fel.cvut.cz. 2. Karel Koci, kocik...@fel.cvut.cz. Two propositions for projects are: 1. Michal Lenc: NXboot. 2. Michal Matias: IEEE 802.3cg. Could you please prepare required descriptions for the projects? If there are any other students and projects that may benefit from GSoC2025 please prepare descriptions for them too :-) All process needs to complete by the end of march (deadline is 20250402). Thank you! :-) Tomek On Thu, Mar 20, 2025 at 12:31 PM Pavel Pisa wrote: Dear Alan, Tomek and others, Michal Matias already reported that he is working on the IEEE 802.3cg 10BASE−T1S support in the frame of his bachelor thesis. The target is ESP32C6 and ONsemi NCV7410. He consider to continue and extend the work in the frame of NuttX GSoC to support more targets and finish beacon mode synchronization etc. I think that it would wort to register topic for him at https://cwiki.apache.org/confluence/display/COMDEV/GSoC+2025+Ideas+list I should have account there but I am not fully sure through which project it should be submitted. Another problem is that I should not be the main mentor/reviewer of his work, because we are too close at the university. Please, who is willing to be mentor/reviewer of the project? May it be it can be even Karel Koci from Electroline team, because he considers to use T!S at his house and in longer term at Elektroline. As for the other offered topic from our range, I would be happy to (co-)mentor some them but I am really slow in responses... Too much teaching and projects and Confluence is yet another not so big obstacle to register my ideas. But if there is somebody interested, I would try to revive my account on Confluence and list them... - CAN/CAN FD NuttX API enhancements and deduplication, at start at least bittiming https://github.com/apache/nuttx/issues/15567 - PWM API cleanup, only one API compatible with actual multi channel but with channel count to make overhead minimal for single channel peripherals even if other one is the same build is larger https://github.com/apache/nuttx/issues/12381 - NXboot - Stepan Pressl is working on simple/standalone firmware updater over Silicon-Heaven, the repo for future publication https://github.com/zdebanos/nx-shv-fwupdater The plan is to use it with pysimCoder - pysimCoder related work - porting https://microblocks.fun/ to NuttX, some proof of feasibility (smallvm https://bitbucket.org/john_maloney/smallvm bare core compilation) already done - porting Microwindows/Nano-X on on top of NuttX framebuffer API https://github.com/ghaerr/microwindows/issues/85 As for Michal Lenc work on NXboot, he has well prepared presentation on the local https://installfest.cz/if25/ community conference. The recording in Czech language, as well as slides. But it would be nice topic for some NuttX workshop. Is the date and location already available? If it is not, I can ask at our university and there is chance to obtain our facilities for the community action with free access to public and our studnets for free or very low price... Anyway we have success to generate the application from pysimCoder as NXboot update image and send it to the target over silicon-heaven which has been used after update and reboot to communicate with running model and tune its parameters from SHVspy and even directly pysimCoder block diagram. Best wishes, Pavel Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa social: https://social.kernel.org/ppisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home On Tuesday 18 of March 2025 15:40:30 Alan C. Assis wrote: Let's announce it on LinkedIn too! It is important to list the proposals in the Apache Site, there are some from previous years that could be used: NanoX Graphic support, etc BR, Alan On Tue, Mar 18, 2025 at 11:26 AM Tomek CEDRO wrote: Ladies and Gentlemen, it is time to register and announce our NuttX Mentors and Contributors for
[VOTE] Change setlogmask behavior to POSIX standard
Hi all, I've submitted pull request that changes setlogmask function behavior to the one expected by POSIX standard <https://github.com/apache/nuttx/pull/16280>. The description of the change is provided in the mailing list, to summarize it, our implementation uses zero argument to set logging mask to zero and thus disable the logging at all. However, POSIX clearly states that passing zero argument should not modify the current logging mask, but just return the old one. We should change the behavior to comply with POSIX standards here. As Tomek suggested, we should vote here first, because this is a potential breaking change for existing applications. So let's vote for/against the change. It's also worth noting that POSIX probably (or at least I haven't found a way) doesn't allow to disable all logging at runtime, just to set the mask to the highest priority (lowest amount of messages, just emergency logs) with LOG_EMERG (or any other priority you want). Nevertheless, I consider the POSIX (and Linux) compatibility more important in this case and vote for the change. Thanks, Michal
Setlogmask behavior not in compliance with POSIX
Hi all, just bringing the attention to the mailing list as well. I have submitted a pull request that fixes the behavior of setlogmask function. POSIX standard states passing zero mask as an argument should not modify the current logging mask and just return it. However, our NuttX implementation uses 0 to disable the logging. This is in a violation with POSIX standard and thus with The Inviolable Principles of NuttX (strict POSIX compliance part). It also makes Linux <-> NuttX application porting harder as the behavior is different compared to other POSIX systems. Feel free to share your thoughts here or in the pull request comments, but I think it shouldn't be a problem to merge the fix. It is, however, a breaking change. The PR: https://github.com/apache/nuttx/pull/16280 Best regards, Michal
Re: Make nxboot img_header public?
Hi Tim, If I remember correctly, these structures are public now, you should be able to include from your application. Best regards, Michal On 4/29/25 19:48, Tim Hardisty wrote: I am adding enhancements to my custom image booting software (that copies the image from flash to internal SDRAM). As part of that I would like, via PR, to expose /struct nxboot_img_header/ and it's associated /struct nxboot_hdr_version/ and /struct nxboot_img_version/ via a public header file (apps/include/nxboot/nxboot.h). It will allow me to get the actual image size for copying rather than the entire "slot" size, as well as to be able to extract the image version information for use by my app. Can anyone see any problems with this?
Re: [VOTE] Change setlogmask behavior to POSIX standard
Hi, it's been 72 hours since the vote start with 7 +1 votes and no 0 or -1 votes. I think we can close the vote now and I'll mark the pull request as ready. Thanks. Michal On 4/29/25 08:37, Michal Lenc wrote: > Hi all, > > I've submitted pull request that changes setlogmask function behavior to > the one expected by POSIX standard > <https://github.com/apache/nuttx/pull/16280>. The description of the > change is provided in the mailing list, to summarize it, our > implementation uses zero argument to set logging mask to zero and thus > disable the logging at all. However, POSIX clearly states that passing > zero argument should not modify the current logging mask, but just > return the old one. We should change the behavior to comply with POSIX > standards here. > > As Tomek suggested, we should vote here first, because this is a > potential breaking change for existing applications. So let's vote > for/against the change. > > It's also worth noting that POSIX probably (or at least I haven't found > a way) doesn't allow to disable all logging at runtime, just to set the > mask to the highest priority (lowest amount of messages, just emergency > logs) with LOG_EMERG (or any other priority you want). Nevertheless, I > consider the POSIX (and Linux) compatibility more important in this case > and vote for the change. > > Thanks, > > Michal >
Re: Problem with running nuttx on imxrt1020
On 2025-02-17 08:48:28, Simin Feng (CW) wrote: > dump_assert_info: Assertion failed panic: at file: :0 task: Idle_Task > process: Kernel 0x600031dd Seems like you need to enable debug as there is file and line missing from log. Enable debug symbols and more debug prints, also canaries for stack monitoring and try to rerun - maybe some more useful information will be revealed. -- .-.---.--.-----. | 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 | `--^--^--^-' signature.asc Description: PGP signature
