Re: RFC - AVR fixes and support for AVR DA/DB family
Is server broken? I get 403 on https://git.kerogit.eu/apache/nuttx.git and anything else in kerogit.eu domain :-( Tomek On Sun, May 4, 2025 at 4:44 PM wrote: > > Hello, > > new version of the patch series is posted in the git repository, the > branch is named avrdx_rfc2 and starts at avr_fixes_rfc2 (everything up > to and including avr_fixes_rfc2 is already merged.) > > Here are the changes from previous version: > > 1. some formatting and typo fixes in various documents > > 2. as discussed above, some mixed-case constants were preserved (_bm and > _bp suffix) and some removed. Patch for the nxstyle tool that > facilitates this exception is added to the series. Non-permitted > constants with mixed-case letters are no longer used in their form from > library io.h file, instead there are new files within NuttX source tree > that provide all-uppercase constant names. > > 3. nxstyle cannot deal with the exceptions properly and come constants > with _bm suffix in their name were still flagged as incorrect. That is > worked around by various code shuffling, assigning into temporary > variables etc. Most places where this was needed to be done are marked > with comment along the lines of "this will make nxstyle happpy." The > code seems less readable this way but after trying to make heads or > tails of the nxstyle source code, this is the only solution I can > provide on my own. > > 4. after dealing with this, I found that there were some mixed-case > warnings still left - I missed them because of the quantity of others. > Specifically, it was the type USART_t, a data type which facilitates > access to a peripheral I/O registers for USART. (Other peripherals have > their types named in the same way.) I changed this one into > avrdx_usart_t and redefined it in the NuttX source as well. > > There should be no checkpatch errors left. > > From what I tested, the code compiles to a binary identical to previous > version of the patch series. > > Any comments and reviews are appreciated. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: RP2040 multiple GPIO interrupts
Hello world! Any RP2040 users feedback is welcome on this change as Kevin tired it and reported some issues :-) Thanks! :-) Tomek On Tue, Apr 29, 2025 at 2:24 AM Matteo Golin wrote: > > Hello everyone, > > In order to solve this issue, I have opened a PR here: > https://github.com/apache/nuttx/pull/16281 > > This allows multiple GPIO interrupt types to be selected once, since the > RP2040 supports that. Now one GPIO pin can trigger up to 4 interrupt events. > > I would appreciate your review! > Matteo > > On Tue, Mar 18, 2025 at 4:36 PM Kevin Witteveen > wrote: > > > Hey Matteo, > > > > It appears the RP2040 can support falling and rising interrupts at once > > according to the RP2040 datasheet section 2.19.5.2 "Enable a GPIO > > interrupt", which provides an example of how to do this. > > Ofcourse this example is not NuttX, but can help for implementation. > > https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf > > > > Maybe this can help you find a solution. > > > > Best regards, > > > > Kevin > > > > > > Op di 18 mrt 2025 om 21:25 schreef Alan C. Assis : > > > > > Hi Matteo, > > > > > > I think RP2040 and new RP2350 are good MCUs, but Raspberry Pi Foundation > > > did some terribles mistakes, like using a serial port control that > > doesn't > > > have indication of transmission done (useful for RS485 support) and GPIO > > > INT with both edges support. > > > > > > When I created the ultrasound sensor driver (drivers/sensors/hc_sr04.c) I > > > already considered that some "cheap" MCU will not have support for both > > > edge detection, so initially I detect the raising signal and when that > > > interrupt happens I change the GPIO to detect falling edge. Look at > > > hcsr04_start_measuring() and hcsr04_int_handler(). > > > > > > BR, > > > > > > Alan > > > > > > On Tue, Mar 18, 2025 at 5:07 PM Matteo Golin > > > wrote: > > > > > > > Thank you everyone for the suggestions. > > > > > > > > I don't have enough GPIO pins to dedicate two per switch unfortunately, > > > nor > > > > do I have a suitable hardware method for handling debouncing. I suppose > > > > this is taken care of in the button driver framework via software, but > > > not > > > > for the bare GPIO framework. I don't believe the button framework will > > > work > > > > for this application because the switches are toggle switches, not > > > buttons. > > > > > > > > I like Marco's solution of switching the interrupt type on the toggle, > > > but > > > > I am fearful of the race conditions you mentioned, Nathan. I suppose I > > > > could take the interrupt type toggling approach but read the > > interrupted > > > > pin in software with a delay to ensure the correct value, which would > > > > remedy the debouncing issue? I believe this can be done from > > application > > > > code at least. That still leaves the issue of the interrupt type not > > > being > > > > toggled in time for the next edge, which could miss an input. I was > > > hoping > > > > there would be a method to attach both a rising and falling edge > > > interrupt > > > > handler to the GPIO pin simultaneously but it appears the current > > RP2040 > > > > support doesn't allow that, although the chip itself does. Maybe that > > > would > > > > be a feature worth adding? > > > > > > > > Thanks again for the suggestions, I'll have to do some thinking but > > maybe > > > > the polling approach is the safest bet. > > > > > > > > Matteo > > > > > > > > On Tue, Mar 18, 2025 at 8:23 AM Nathan Hartman < > > hartman.nat...@gmail.com > > > > > > > > wrote: > > > > > > > > > On Mon, Mar 17, 2025 at 5:18 PM Matteo Golin > > > > > > > wrote: > > > > > > > > > > > Hello everyone, > > > > > > > > > > > > I have an application wherein I am using a W5500-EVB Pico as the > > MCU > > > > for > > > > > a > > > > > > network controlled system. I need to connect > > > > > > several switch inputs into this MCU. The switches are normally held > > > > high > > > > > > via the RP2040's internal pullups, and pulled > > > > > > low when flipped. > > > > > > > > > > > > > > > > > > > > By switch inputs, do you mean physical switches, like toggle > > switches? > > > If > > > > > so, then I hope you're handling switch debouncing somehow, either by > > > > > software (multiple consecutive identical readings, spaced apart by > > some > > > > > constant time interval, must occur before reacting to the change in > > > > switch > > > > > state) or by hardware (at the very least a RC network with a schmitt > > > > > trigger). Otherwise, if you interrupt on rising and falling edges, > > > you'll > > > > > likely see spurious interrupts and unwanted state changes. > > > > > > > > > > > > > > > The problem I'm encountering is that it appears that the current > > RP2040 > > > > > > support only allows for one type of interrupt > > > > > > per pin: either rising edge or falling edge. I need to trigger on > > > both > > > > > > rising and falling edge to accurately track the > > > > > > state of the switch
Re: How to enable rcS script in nucleo-stm32h753zi
Hi Karukkuvel, There is a 7 years video tutorial here: https://www.youtube.com/watch?v=jYvCe8yQ1OY It is from an old version of NuttX, but could help you to get it working. Also there is an official Documentation here: https://nuttx.apache.org/docs/latest/guides/etcromfs.html#start-up-scripts BR, Alan BR Alan On Mon, May 5, 2025 at 9:12 AM karukkuvel Raj Deivasundaram < karukkuvelraj.deivasunda...@killisbird.com> wrote: > Hi Team > > Hi all, > > I'm currently working with the Nucleo-STM32H743ZI board using NuttX and > would like to automatically launch a user application at boot using an > `rcS` script. > > I understand that the `NSH` configuration supports initialization scripts > through ROMFS. but I'm unsure of the correct steps to fully integrate and > enable it on this board. > > Could anyone guide me on: > > 1. How to properly include the `romfs_img.c` in the build (e.g., best > practices for `Make.defs`). > 2. Whether additional board-specific steps are needed for the STM32H7 > series to mount and use the ROMFS automatically. > 3. How to confirm that the NSH shell is loading and executing the script > from `/etc/init.d/rcS`. > > Any advice or examples from similar STM32 boards would be very helpful. > > Thanks in advance for your time and support. > Regards > Karukkuvel Raj D > Flight Controls Engineer > >
How to enable rcS script in nucleo-stm32h753zi
Hi Team Hi all, I'm currently working with the Nucleo-STM32H743ZI board using NuttX and would like to automatically launch a user application at boot using an `rcS` script. I understand that the `NSH` configuration supports initialization scripts through ROMFS. but I'm unsure of the correct steps to fully integrate and enable it on this board. Could anyone guide me on: 1. How to properly include the `romfs_img.c` in the build (e.g., best practices for `Make.defs`). 2. Whether additional board-specific steps are needed for the STM32H7 series to mount and use the ROMFS automatically. 3. How to confirm that the NSH shell is loading and executing the script from `/etc/init.d/rcS`. Any advice or examples from similar STM32 boards would be very helpful. Thanks in advance for your time and support. Regards Karukkuvel Raj D Flight Controls Engineer [cid:296329a6-5acd-4136-a1dc-e6e866df2d33]
Re: RFC - AVR fixes and support for AVR DA/DB family
Hi, it's just /nuttx.git without the /apache part. On 2025-05-05 17:46, Tomek CEDRO wrote: Is server broken? I get 403 on https://git.kerogit.eu/apache/nuttx.git and anything else in kerogit.eu domain :-( Tomek On Sun, May 4, 2025 at 4:44 PM wrote: Hello, new version of the patch series is posted in the git repository, the branch is named avrdx_rfc2 and starts at avr_fixes_rfc2 (everything up to and including avr_fixes_rfc2 is already merged.) Here are the changes from previous version: 1. some formatting and typo fixes in various documents 2. as discussed above, some mixed-case constants were preserved (_bm and _bp suffix) and some removed. Patch for the nxstyle tool that facilitates this exception is added to the series. Non-permitted constants with mixed-case letters are no longer used in their form from library io.h file, instead there are new files within NuttX source tree that provide all-uppercase constant names. 3. nxstyle cannot deal with the exceptions properly and come constants with _bm suffix in their name were still flagged as incorrect. That is worked around by various code shuffling, assigning into temporary variables etc. Most places where this was needed to be done are marked with comment along the lines of "this will make nxstyle happpy." The code seems less readable this way but after trying to make heads or tails of the nxstyle source code, this is the only solution I can provide on my own. 4. after dealing with this, I found that there were some mixed-case warnings still left - I missed them because of the quantity of others. Specifically, it was the type USART_t, a data type which facilitates access to a peripheral I/O registers for USART. (Other peripherals have their types named in the same way.) I changed this one into avrdx_usart_t and redefined it in the NuttX source as well. There should be no checkpatch errors left. From what I tested, the code compiles to a binary identical to previous version of the patch series. Any comments and reviews are appreciated.
Re: Make nxboot img_header public?
On Tue, Apr 29, 2025 at 7:49 PM 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: GSoC project
On Wed, Apr 30, 2025 at 11:15 PM Ujjval Rathod wrote: > I saw some open projects for Nuttx at GSoC 2025. > > I am interested in project on spe SPIMAC support. > > Can anyone contact me further for that? > > > Regards, > Ujjval >
Re: RFC - AVR fixes and support for AVR DA/DB family
Okay, git clone works from that location, I pushed the PR but Alan is working on this one too so he takes over, thanks for your contributions KR! Two remarks: 1. Please remember to git commit -s. 2. Please remember to mark what hardware was the code tested on. https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md Thank you! :-) Tomek On Mon, May 5, 2025 at 7:47 PM wrote: > > Hi, it's just /nuttx.git without the /apache part. > > On 2025-05-05 17:46, Tomek CEDRO wrote: > > Is server broken? I get 403 on https://git.kerogit.eu/apache/nuttx.git > > and anything else in kerogit.eu domain :-( > > Tomek > > > > On Sun, May 4, 2025 at 4:44 PM wrote: > >> > >> Hello, > >> > >> new version of the patch series is posted in the git repository, the > >> branch is named avrdx_rfc2 and starts at avr_fixes_rfc2 (everything up > >> to and including avr_fixes_rfc2 is already merged.) > >> > >> Here are the changes from previous version: > >> > >> 1. some formatting and typo fixes in various documents > >> > >> 2. as discussed above, some mixed-case constants were preserved (_bm > >> and > >> _bp suffix) and some removed. Patch for the nxstyle tool that > >> facilitates this exception is added to the series. Non-permitted > >> constants with mixed-case letters are no longer used in their form > >> from > >> library io.h file, instead there are new files within NuttX source > >> tree > >> that provide all-uppercase constant names. > >> > >> 3. nxstyle cannot deal with the exceptions properly and come constants > >> with _bm suffix in their name were still flagged as incorrect. That is > >> worked around by various code shuffling, assigning into temporary > >> variables etc. Most places where this was needed to be done are marked > >> with comment along the lines of "this will make nxstyle happpy." The > >> code seems less readable this way but after trying to make heads or > >> tails of the nxstyle source code, this is the only solution I can > >> provide on my own. > >> > >> 4. after dealing with this, I found that there were some mixed-case > >> warnings still left - I missed them because of the quantity of others. > >> Specifically, it was the type USART_t, a data type which facilitates > >> access to a peripheral I/O registers for USART. (Other peripherals > >> have > >> their types named in the same way.) I changed this one into > >> avrdx_usart_t and redefined it in the NuttX source as well. > >> > >> There should be no checkpatch errors left. > >> > >> From what I tested, the code compiles to a binary identical to > >> previous > >> version of the patch series. > >> > >> Any comments and reviews are appreciated. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
