Re: git going rust

On Fri, Sep 5, 2025 at 5:51 PM Tomek CEDRO wrote: > > https://lore.kernel.org/git/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0...@pks.im/T/#t > > :-( > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > There's an easy fix for that. Just switch to Subversion ;-)

Re: NuttX Hardware Survey 202508

On Mon, Sep 1, 2025 at 2:58 PM Tomek CEDRO wrote: > 4. Code owners, we tried, maybe we should retry. I like the idea that > if someone contributes somewhere that means they have insight and will > help others so they will be assigned to "ownership" based on git > history :-) Hmm, "code owners"

Re: [NXDART] NuttX Hardware Survey / gathering ideas and feedback

On Tue, Aug 26, 2025 at 10:29 PM Tomek CEDRO wrote: > Oops, again with reduced size pictures (sorry for non-plaintext email) ;-) > > On Wed, Aug 27, 2025 at 4:09 AM Tomek CEDRO wrote: > >> Thank you everyone for initial testing and feedback on the "draft" >> version of the NuttX Hardware Survey

Re: Porting renesas DA1470X - stuck

On Thu, Aug 7, 2025 at 4:18 PM Luca Giambonini wrote: > Dear nuttx team, > I'm working in my very little spare time on the porting of nuttx to DA1470 > Renesas MCU on a da1470x_pro_dev_kit. > This is my very first port, so it has taken me a while to dig into and > understand how NuttX brings up a

Re: New type of input idea: an action button

On Wed, Jul 9, 2025 at 12:38 PM Gregory Nutt wrote: > The time delay that you are concerned about is simply the context > switching time and this is necessary to instantiate the thread's stack and > other operating context. As a general rule this restoration of thread > context cannot really be

Documentation in nuttx-apps repository?

Hi all, Right now, Documentation is in the main nuttx repository [1]. However, some of the Documentation there pertains to the nuttx-apps repository. One current example is PR #16665 in nuttx repo, which is documenting the new Xedge example located in the nuttx-apps repo. I think it's a little b

Re: CTU OTREES theses, more related to NuttX and RISC-V Was: book: RISC-V System-On-Chip Design. [resent]

Should any of these be mentioned in the NuttX website, maybe in a new "Who's Using NuttX" section? On Mon, Jun 23, 2025 at 1:27 AM Alin Jerpelea wrote: > Hi Pavel, > > thanks for sharing the information > > Best regards > Alin > > > On Sun, 22 Jun 2025, 09:48 Pavel Pisa, wrote: > > > Hello ever

Re: X11 vs Wayland: KiCAD story.

On Wed, Jun 18, 2025 at 8:48 AM Tomek CEDRO wrote: > https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/ > > Looks like (self-)compatibility problem of enforced changes solutions > is arising in the Open-Source world and statements are made in more > and more projects :-) > > -- > CeDeR

Re: [OT] NuttX Standard Board

Hi all, I have a few suggestions:: 1. I suggest to request INFRA to create a new repository for the design and implementation of hardware, which initially will contain the NuttX Standard Board hardware. I suggest the name nuttx-hardware. 2. Within the nuttx-hardware repository, I suggest to have

Re: Changing USART baud rate in sensor driver

On Thu, Jun 5, 2025 at 3:37 PM Elias Hawa wrote: > Hello everyone, > > I'm currently working on a sensor driver for the Quectel L86-M33 GNSS > module. It communicates over UART and is very feature rich, allowing users > to send commands over UART to modify things such as position fix interval > a

Re: SYSLOG over the network

On Tue, Jun 3, 2025 at 5:01 PM Matteo Golin wrote: > Hello everyone, > > I was taking a look at the different syslog output options, and I noticed > that there are a variety of different sinks > (character devices, CDCACM, RAM, etc). However, I was thinking that it > would be useful to have a net

Re: GitHub NuttX master branch protections

cess. > > > > But we are locked out from merging the fix ourselves now. The fix is > > here https://github.com/apache/nuttx/pull/16336 :-) > > > > This reference https://github.com/apache/infrastructure-asfyaml may be > > updated with above hints / possible probl

Re: GitHub NuttX master branch protections

Build fails then PR cannot be merged. > > Thank you :-) > Tomek > > On Tue, May 6, 2025 at 6:42 PM Nathan Hartman > wrote: > > > > Hello Tomek :-) > > > > Thanks for doing that! > > > > I have found that the easiest/quickest way to talk to the Infr

Re: GitHub NuttX master branch protections

Hello Tomek :-) Thanks for doing that! I have found that the easiest/quickest way to talk to the Infra folks is by Slack [1]. If you don't want to use Slack, you can write to Infra's users list (also see [1]). I recommend to try slack, but either way, give them the link to the PR and ask nicely

Re: [VOTE] Change setlogmask behavior to POSIX standard

+1 from me Thanks, On Tue, Apr 29, 2025 at 2:39 AM Michal Lenc wrote: > Hi all, > > I've submitted pull request that changes setlogmask function behavior to > the one expected by POSIX standard > . The description of the > change is provided in the ma

Re: [RFC] How to improve NuttX quality and reliability

I like all of these ideas and would like to add: * static analysis can find simple mistakes that might have been introduced. Things like a function that forgot to return a value in some code path, or use of uninitialized variable, can be caught by static analysis. By the way, did some recent chang

Re: Documentation tags for boards

So this would be like a cross-vendor parametric search for boards... cool! It would also be helpful if this kind of parametric search could be part of the NuttX website. This way, visitors who hear about NuttX can see the great number of supported boards and choose one for their project. They migh

Re: [EXT] socketcan ioctl(...SIOCSCANBITRATE...) brings the interface up

On Tue, Apr 15, 2025 at 1:25 PM Carlos Sanchez wrote: > Related PR on the apps side, to make slcan work after the "bitrate no > longer brings interface up" change: > https://github.com/apache/nuttx-apps/pull/3059 > > While testing this, I think I have discovered a small mistake on my > previous,

Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM

-1 from me also, but please read further: I would vote +1 if there is a Kconfig to select crc16 type, and current (backwards-compatible) type is default. This way, existing applications will not break suddenly, but developers who need different CRC can choose it from Kconfig. In addition, I like

Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM

not, not > important. it's just optimization at this point. > > -later: > > * remove the legacy crc16 > > * do the same for any other crc function like crc32 if available. > > > What does the community think about that ? > > > Sebastien > > >

Re: Vote for default crc16 directory to be CRC-16/XMODEM or CRC-16/IBM

I think the real problem here is that the function is called crc16() with no details about which CRC polynomial is used. Maybe it's better not to have this function at all and to have *only* functions with names like crc16ibm() or crc16ccitt(). Then it is much more clear what CRC is being called in

Re: Vote for rename modlib to libelf

+1 On Tue, Apr 8, 2025 at 8:55 AM Tiago Medicci Serrano wrote: > > +1 > > Em seg., 7 de abr. de 2025 às 21:16, Yanfeng Liu > escreveu: > > > +1 > > On Mon, 2025-04-07 at 17:13 +0800, chao an wrote: > > > Hi community, > > > > > > Some green hand and individual developer who are not familiar with

Re: Discuss NXBoot

bination. If there's a framebuffer there's a splash screen by default, and developers can turn that off if they don't want it. > > Maybe we need to think about how to get NXlogo working for LCD_DEV too. > > BR, > > Alan > > On Fri, Mar 28, 2025 at 10:07 AM Nath

Re: Discuss NXBoot

Replying inline below: On Thu, Mar 27, 2025 at 5:15 PM Tim Hardisty wrote: > Hi Nathan, > > Thanks for your thoughts. It has made me think more logically (I hope) > about why and when you might want a splashscreen. > > I'm currently thinking that it is only a pretty "hello world" that > allows

Re: Discuss NXBoot

On Thu, Mar 27, 2025 at 9:18 AM Alan C. Assis wrote: > Hi Tim, > > Yes, maybe it could be an option inside your fbcon app. > > My initial thought was that having a nxlogo inside the kernel (like Linux) > could make it available for all boards that register a framebuffer. If nxlogo is in the ker

Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap

On Wed, Mar 19, 2025 at 5:45 AM Sebastien Lorquet wrote: (snip) > Messing *all* developer working copies with huge diffs just for code > formatting is a no-go. This will prevent bissections and backports. This is by far my biggest concern with code style changes. Bissections, backports, compari

Re: RP2040 multiple GPIO interrupts

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 interna

Re: [EXT] Re: [PROPOSAL] New nxstyle tool roadmap

Hi all, I think we shouldn't make drastic changes to the source style because that will just create a lot of busywork and a lot of source changes that will introduce needless headaches when comparing different revisions etc. Instead, I think we should make only the minimal adjustments to the sour

Re: [PROPOSAL] New nxstyle tool roadmap

Regarding the missing features in clang format, have you considered opening feature requests for these with the clang devs? Regarding a nxtool with multiple subcommands for things, such as style checking, this is an interesting idea that should be explored. My only concern is with the addition of

Re: Proposal: Common IOCTL API for RF Modulation Technologies

Hi all, I like the fact that there has been a high level analysis here and an effort to make things consistent across multiple types of communications. Since the drivers mentioned are experimental, I agree that breaking changes aren't breaking stabilized interfaces. We should just be careful to

Re: [VOTE] ROUND2 NuttX Contributing Guidelines update 202502.

Hi all, A very *BIG* THANK YOU! to Tomek for driving this and doing the work of running the votes and tallying the results! Also THANK YOU to everyone who has participated so far in the discussions and voting. I guess the next steps will be to make any updates to the Contributing Guidelines? Th

Re: [Vote] NuttX LTS release

Hi all, I was going to reply (or maybe I did reply in another thread?) but I don't see it here now. Anyway I'm with you. Even though I would like to see LTS releases (eventually), I agree that we need to get more organized first. Improving our automated testing (on real hardware!) should definitel

Re: [VOTE] ROUND2 NuttX Contributing Guidelines update 202502.

On Thu, Feb 27, 2025 at 8:30 AM Sebastien Lorquet wrote: > > > On 27/02/2025 13:53, Filipe Cavalcanti wrote: > > 1. Contributing Guidelines with hints for Reviewers. > > > We are adding additional section for Reviewers to Contributing > > Guidelines in order to provide checklist and complementar

Re: [VOTE] ROUND2 NuttX Contributing Guidelines update 202502.

I think we should each reply to the original vote email. If we reply to someone else's vote, the votes will get all mixed up like that. On Mon, Feb 24, 2025 at 9:26 AM Tiago Medicci Serrano wrote: > > Hi Alin, > > It seems you mixed my answers and Tomek's together. Can you double-check, > please?

Re: [VOTE] NuttX Contributing Guidelines update 202502.

On Sat, Feb 15, 2025 at 4:53 PM Tomek CEDRO wrote: > > Okay so here goes the vote results :-) Thanks, Tomek, for doing all of this! I would like to add some more of my thoughts: Regarding these rules: 9. Zero trust approach to user testing 10. Breaking changes not welcome. 11. Respect for long

Re: [VOTE] NuttX Contributing Guidelines update 202502.

Hi all, My votes (with notes/commentary below): 1. +1 2. +0.5: See "Note On #2" below. 3. +1 4. +1 5. +1 6. +1 7. +1 8. +1 9. -1: See "Note On #9" below. 10. -0.5: See "Note On #10" below. 11. +1 12. +1 13. +0.5: See "Note On #13" below. 14. -1: See "Note On #14" below. 15. +1. 16. +1. 17. +1. "

Re: [Discuss] LTS releases

is the wrong > approach. > > > wt., 11 lut 2025 o 15:07 Nathan Hartman > napisał(a): > > > I also think LTS point releases should focus on bugfixes and security > only, > > to ensure the maximum stability. > > > > Nathan > > > > On Tue, Feb 11,

Re: [Discuss] LTS releases

I also think LTS point releases should focus on bugfixes and security only, to ensure the maximum stability. Nathan On Tue, Feb 11, 2025 at 8:32 AM Sebastien Lorquet wrote: > Hello, > > I agree. Only bugfixes, criticity threshold to be determined, but new > features seem unnecessary to me. > >

Re: The behavior of spin_lock needs everyone's advice

Even though there are some problems, I am glad that the community is actively addressing them and that we are discussing how to improve in the future. I can't offer advice on the spinlock question at this time because I haven't studied it, but when I ship my current project I should have more time

Re: Explanation request about a the merging of an unacceptable pull request

Maybe we shouldn't merge PRs until at least one reviewer tests on real hardware. It doesn't have to be the same board, but at least the same arch, if it touches arch code. If it's in sched or something shared on all architectures then it's okay to test on any arch. We would need to decide how to ha

Re: arm64 zynq-mpsoc was broken

I think we should restart the conversation about setting up a build and test farm of real hardware, with a diverse collection of boards and processor architectures. It would be a good thing if we could have BOTH a project-owned centralized farm AND a relatively easy way for individual developers an

Re: app/os sync creates many problems

On Fri, Jan 31, 2025 at 3:15 PM 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

Re: app/os sync creates many problems

On Fri, Jan 31, 2025 at 7:50 AM 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 packa

Re: trust in nuttx gone

s > good enough to be LTS release? > As I mentioned before, it's impossible to have a stable base or LTS release > without enough automation test. > > On Thu, Jan 30, 2025 at 4:05 AM Nathan Hartman > wrote: > > > On Wed, Jan 29, 2025 at 8:21 AM Alan C. Assis wrot

Re: trust in nuttx gone

On Wed, Jan 29, 2025 at 3:40 PM Alin Jerpelea wrote: > > LTS is a good idea the only issue is that we can not guarranty that the > patches can be backported for 2 years due to the way PRs are submitted. > most time a change is affecting multiple drivers or subsistems instead of > having separate s

Re: trust in nuttx gone

On Wed, Jan 29, 2025 at 8:21 AM Alan C. Assis wrote: > > Hi Simon, > > Yes, but it important to prove your point using a commercially available > development board. > > NuttX (just like Linux) is a moving target. So one out of tree board always > will break because people are constantly changing t

Re: INA260 device driver (based on ina226 device)

On Sun, Jan 26, 2025 at 11:01 AM Stewart charnell wrote: > Hello, > > I have been working with a ina260 (digital current and power monitor via > ADC) sensor module (I2C interface). I created a device driver based on > the ina226 device. I have found some errors in the ina226 (and ina219) > driver

Re: [Article] Forgejo Git Forge for NuttX (Experimental)

On Sat, Jan 11, 2025 at 10:06 PM Gregory Nutt wrote: > > On 1/11/2025 6:00 PM, Tomek CEDRO wrote: > > On Sat, Jan 11, 2025 at 11:02 PM Lee, Lup Yuen > wrote: > >> What is Forgejo? Think GitHub… But Open-Source and Self-Hosted! Forgejo > is a Git Forge, the server code that will publicly host and

Re: [Article] Experimental Mastodon Server for NuttX Continuous Integration

RSS is an interesting idea. Regardless of the platform, whether email, RSS, Fediverse, whatever, if you want to be notified of important events while avoiding needless noise, it should notify about changes in status only. Meaning, notify when the build breaks, notify when the build passes again, b

Re: Raspberry Pi 4B Preliminary Support

On Tue, Dec 17, 2024 at 11:32 AM Matteo Golin wrote: > Hello everyone, > > Yesterday my PR was merged to add preliminary support for the BCM2711 chip > and Raspberry Pi 4B board. > You can take a look here if you'd like to see the changes: > https://github.com/apache/nuttx/pull/15188 > Thanks aga

Re: Kconfig: select vs depends on

On Tue, Dec 17, 2024 at 8:12 AM wrote: > 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 pref

Re: Request for being member

On Thu, Dec 12, 2024 at 12:56 AM 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

Re: SERIOUS BUG: Zero Latency Interrupts are broken!

On Mon, Dec 9, 2024 at 9:46 PM Xiang Xiao wrote: > > On Tue, Dec 10, 2024 at 5:53 AM Nathan Hartman > wrote: > > > Hi all, > > > > Unfortunately I missed the PR before it was merged, but PR-15073 has > > broken High Priority, Zero Latency Interrupts! For

Re: SERIOUS BUG: Zero Latency Interrupts are broken!

On Tue, Dec 10, 2024 at 9:06 AM Gregory Nutt wrote: > On 12/10/2024 7:59 AM, Nathan Hartman wrote: > > On Tue, Dec 10, 2024 at 8:11 AM spudaneco wrote: > > > >> I wonder if we should also disable the prioritization APIs. In the > >> normal, default cas

Re: SERIOUS BUG: Zero Latency Interrupts are broken!

On Tue, Dec 10, 2024 at 8:11 AM spudaneco wrote: > I wonder if we should also disable the prioritization APIs. In the > normal, default case, any reprioritization of an IRQ introduces a fatal, > mysterious bug. That is because nested interrupts will occur and may not > be supported.Sent from my

Re: SERIOUS BUG: Zero Latency Interrupts are broken!

On Mon, Dec 9, 2024 at 9:46 PM Xiang Xiao wrote: > > On Tue, Dec 10, 2024 at 5:53 AM Nathan Hartman > wrote: > > > Hi all, > > > > Unfortunately I missed the PR before it was merged, but PR-15073 has > > broken High Priority, Zero Latency Interrupts! For

SERIOUS BUG: Zero Latency Interrupts are broken!

Hi all, Unfortunately I missed the PR before it was merged, but PR-15073 has broken High Priority, Zero Latency Interrupts! Fortunately I caught it now. It was merged 17 hours ago. This PR removed a very important Kconfig: config ARMV7M_USEBASEPRI, and much of the logic related to it. This config

Re: [POSIX][Bug] mqueue.h: Include file does not conform the standard (#15085)

On Mon, Dec 9, 2024 at 5:57 AM Javier Alonso wrote: > Good morning NuttX devs, > > This is Javi. I'm writing you regarding a compliant bug regarding the > mqueue header and POSIX. The IEEE Std 1003.1-2024 states that some > symbols should be exposed when doing #include but are missing > in the "

Filling unused flash with trap instructions?

I was reading an application note that discusses dealing with Electrical Fast Transients (EFT) and other issues that could cause malfunctions in embedded systems. The application note is at [1]. One of the suggestions is "filling unused program memory with a trap instruction sequence to stop the r

Re: New Board / New Chip

On Wed, Nov 27, 2024 at 3:42 AM Simon Filgis wrote: > Dear all, > > I would like to add a board with STM32F030R8. I started with copying > STM32F051-DISCOVERY. In menuconfig I can select the correct chip. > > I need to add defines in nuttx/include/arch/stm32f0l0g0/chip.h > > Then the build fails

Re: Change time_t to signed type

Thank you, Greg, for doing this research and putting this all together here! This stood out (replying below): On Wed, Nov 6, 2024 at 8:11 AM Gregory Nutt wrote: > * Linux originally used a 64-bit > |time_t| for 64-bit architectures only; the pure 32-bi

Re: Change time_t to signed type

On Tue, Nov 5, 2024 at 3:07 PM Tomek CEDRO wrote: > > Yet another (probably silly) idea: how about giving choice if 32 > and/or 64 bit time is signed or unsigned in the kconfig and the > summary warning at the end of build? This way developers could select > what they want to use? This could give

Re: FAT FS on mtd partition of NOR flash

On Thu, Oct 31, 2024 at 2:51 PM Alan C. Assis wrote: > Hi Tim, > > It would be nice if you can write down the steps you took, if you have a > blog to document it. Or put it directly in NuttX's Documentation. It will be helpful for others! Maybe a document about "How To Use File Systems" with

Re: [Article] Your very own Build Farm for NuttX

On Mon, Oct 28, 2024 at 4:42 AM Alin Jerpelea wrote: > Hi all, > > is anyone aware of this warning ? > riscv-none-elf-ld: warning: /nuttx/nuttx has a LOAD segment with RWX > permissions > > Best regards > Alin That looks like it should be added as a bug in the issue tracker. Cheers, Nathan

Re: [Article] Your very own Build Farm for NuttX

Nice article Lup! Thank you. A few questions: 1) Regarding the script that uploads CI results to github gists: will this work for anyone who runs the docker image? If not, what should be done with the results? 2) Is there a way to detect (like a GPIO rising or falling edge, for lack of a better d

Re: [URGENT] Reducing our usage of GitHub Runners

and still have the same quote that > NuttX (the 5th most active project under Apache umbrella). > > I remember Greg said that when moving to Apache we will have all the > resources we were looking for a long time, like: CI, hardware test > integration, funding for our events

Re: [URGENT] Reducing our usage of GitHub Runners

Hi folks, The following email was posted to builds@ today and might contain something relevant to reducing our GitHub runners? Forwarded message below... [1] https://lists.apache.org/thread/pnvt9b80dnovlqmrf5n10ylcf9q3pcxq -- Forwarded message - From: Lari Hotari Date: Tue, Oct

Re: Microchip introduces the PIC64 quad-riscv cpu

Of course, in addition to Linux-capable, they list Zephyr RTOS... NuttX should totally work on this chip! On Mon, Oct 14, 2024 at 10:33 AM Sebastien Lorquet wrote: > Looks like a cool chip, have a look: > > > https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ProductDocuments/Broch

Re: NuttX "gadget": resolve its host name via CDC/NCM connection

Isn't there Bonjour/Avahi that can make something like this work on a local network, at least when accessed from a computer that supports Bonjour/Avahi? I think this is how printers are automatically discovered on a network. On Wed, Oct 9, 2024 at 9:02 AM Tim Hardisty wrote: > > Yes - I think mDN

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

On Sun, Sep 29, 2024 at 9:16 AM Simon Filgis wrote: > Hi Mr. Lup, > > I like! > > The LLM should not only check the commenting around the code. > > It should also try to review the code. > 1. Commented and easy to understand? Simplify naming suggestions. > 2. Efficient algorithms? Suggest differe

Re: Questions about STM32 support/programming

On Fri, Sep 27, 2024 at 2:24 AM wrote: > 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 >

Re: Amateur Rocketry Team Contributors

On Wed, Sep 25, 2024 at 6:36 PM Matteo Golin wrote: > > Hello everyone, > > My name is Matteo, and I am a lead on Carleton University's rocketry > engineering design team (called CU InSpace). We're > based out of Ottawa, Canada and we design and build high powered sounding > rockets every year.

Re: Help need to understand Nuttx build process

On Thu, Sep 5, 2024 at 9:37 PM Gregory Nutt wrote: > One more time... I meant to respond to the list. > > On 9/5/2024 6:54 PM, Ritvik Tanksalkar wrote: > > Hi Gregory, > > > > Thanks alot for pointing me to the correct documentation, just what I > > needed!. > > > > Warm Regards, > > Ritvik Tanks

Re: handling exceptions in C / NuttX

On Thu, Sep 5, 2024 at 9:02 PM Tomek CEDRO wrote: > Hello world :-) > > I am working more in C recently than in for instance Python. Using > structures with pointers to structures or even pointers to functions > with pointer parameters. The problem is for instance some pointers > will not always

Re: MFRC522 Nuttx debug ouput request

If I understand correctly, something is failing when trying to bring up the RFID sensor? Does the board start up if you remove support for the sensor? Do you have oscilloscope or logic analyzer to verify signals are being sent/received between microcontroller and sensor chip? Do you have a debug

Re: Help us to create a distributed board testing farm

CEDRO wrote: > On Fri, Aug 9, 2024 at 3:42 AM Nathan Hartman > wrote: > > On Thu, Aug 8, 2024 at 8:58 PM Gregory Nutt wrote: > > > On 8/8/2024 6:48 PM, Nathan Hartman wrote: > > > > A dedicated "citest" program is a good idea! > > > I think that

Re: Help us to create a distributed board testing farm

On Thu, Aug 8, 2024 at 8:58 PM Gregory Nutt wrote: > > On 8/8/2024 6:48 PM, Nathan Hartman wrote: > > A dedicated "citest" program is a good idea! > I think that ostest could meet all of the needs of a "citest" program. > I just needs more control of the v

Re: Help us to create a distributed board testing farm

A dedicated "citest" program is a good idea! The tests would need to be designed so that when a test passes, certain variables would have certain values, which can be tested to produce the PASS/FAIL result. It will be tricky to design these tests, but it will be extremely valuable for verifying t

Re: Compiling NuttX with system stdlib instead of custom stdlib

Could you tell us a bit about what problem you're trying to solve by using the host system's glibc? As Greg explained, that isn't really feasible, but perhaps if we understand what you're trying to accomplish, someone might be able to suggest a different approach... Cheers Nathan On Fri, Aug 2, 2

Re: Guides for understanding the kernel

know if you have any questions about NuttX on > PinePhone (Arm64 Cortex-A53) > > (Thanks Nathan :-) > > Lup > > On Thu, Jul 25, 2024 at 9:34 PM Nathan Hartman > wrote: > > > Hi Matteo, > > > > The blog of Lup Yuen LEE is a very valuable resource. Lup did a

Re: Guides for understanding the kernel

Hi Matteo, The blog of Lup Yuen LEE is a very valuable resource. Lup did a port of NuttX to PinePhone, which is a 64-bit architecture that could be said to be on a similar level to RPi 4B. There are many other articles that you will likely find helpful: https://lupyuen.codeberg.page/ I recommen

Re: [VOTE] Apache NuttX 12.6.0 RC0 release

On Tue, Jul 23, 2024 at 10:56 AM Tiago Medicci Serrano wrote: > > -1 > > Wi-Fi-related configurations for ESP32, ESP32-S3, ESP32-C3 and ESP32-C6 are > broken because (probably) https://github.com/apache/nuttx/pull/12560 is not > on the release candidate. Can you try to apply that PR and see if i

Re: basically, I get an error when I do make

Thanks for those references. That makes sense. On Sun, Jul 21, 2024 at 8:04 PM Gregory Nutt wrote: > > > > > On 7/21/2024 5:47 PM, Gregory Nutt wrote: > >> > >> On 7/21/2024 5:38 PM, Nathan Hartman wrote: > >>> Hi Alan, > >>> > >

Re: basically, I get an error when I do make

just created a simple main from > scratch. > > The main (no pun intended) issue in the original documentation was because > it wasn't creating a main function for custom hello: > > > https://github.com/apache/nuttx/commit/a1a0315b9cb6cca373f70ae32b9b1ec3cff526d3 > > BR, >

Re: basically, I get an error when I do make

Hi all, I have opened pull request PR-12742 [1] to improve the "---help---" text of this Kconfig and hopefully help others avoid this same issue: [1] https://github.com/apache/nuttx/pull/12742 Cheers, Nathan On Sat, Jul 20, 2024 at 8:40 AM Linotte Justin ... wrote: > > hello, i'm happy you res

Re: Using const in function arguments.

IX violation to use whatever prototype > you happen to like most. No one gets to "improve" POSIX. > > read() is specified here > https://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html and > must *not* include const in the prototype. > > On 7/13/2024 9:00 P

Re: Using const in function arguments.

Replying inline below... On Sat, Jul 13, 2024 at 3:21 PM Petro Karashchenko < petro.karashche...@gmail.com> wrote: > Hi, > > This comes more to the edge of coding language paradigms, personal > preferences and readability. > For enable in Rust everything that you define is "const" and if you want

Re: Using const in function arguments.

Hi Saurav, I think it comes down to whether a parameter like "const uint8_t * const" is C89-compatible. I can't seem to find a reference that gives me a definitive answer to this question, but it *might* have originally been a C++ feature that became standard C at some point. Whether that happened

Re: Improving NuttX Awareness

On Tue, Jul 9, 2024 at 3:36 PM Alan C. Assis wrote: > Thank you very much Gábor, I think having some nice tutorials like you have > for LVGL will help many people! > > Something that people always asked me to do in the NuttX Channel videos was > create some real file application examples. On th

Re: How to improve/simplify NuttX initialization processes?

On Tue, Jul 9, 2024 at 11:42 AM wrote: > On 2024-07-09 09:21:32, Gregory Nutt wrote: (snip) > 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 m

Re: How to demystify some myths about NuttX

not. I > > had to navigate around the help command of the configure tool and find > the > > list of boards (I hadn't checked the directory structure yet, I was still > > setting it up). > > - As back then my main target was to build and run nuttx, I wanted to > ch

Re: How to demystify some myths about NuttX

Replies inline below: On Tue, Jul 9, 2024 at 11:06 AM wrote: > On 2024-07-09 09:49:16, Alan C. Assis wrote: (snip) > 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 rathe

Re: Fwd: Rust Integration in Apache NuttX Apps: GSoC 2024 Mid-Term Recap

ex=13 > > Lup > > On Tue, Jul 9, 2024 at 2:47 AM Alan C. Assis wrote: > > > He converted a GPIO example to Rust, it will not replace anything... > > > > Just like CMakefiles, you choose what to use. > > > > BR, > > > > Alan > > >

Re: How to demystify some myths about NuttX

Documentation needs to explicitly have two sections: * NuttX without a shell (booting directly into your custom firmware application) * NuttX with a shell: booting into NSH Within NuttX with a shell, we should explain: * Purpose of NSH: * Example of how to program and use many OS features *

Re: Fwd: Rust Integration in Apache NuttX Apps: GSoC 2024 Mid-Term Recap

Thank you! Nathan On Mon, Jul 8, 2024 at 2:47 PM Alan C. Assis wrote: > He converted a GPIO example to Rust, it will not replace anything... > > Just like CMakefiles, you choose what to use. > > BR, > > Alan > > On Mon, Jul 8, 2024 at 3:24 PM Nathan Hartman > wr

Re: Fwd: Rust Integration in Apache NuttX Apps: GSoC 2024 Mid-Term Recap

On Mon, Jul 8, 2024 at 1:22 PM Alan C. Assis wrote: > Hi Sebastien, > > You are jumping to conclusions: converting C to Rust doesn't mean kernel > code will be converted, it means Applications code conversion! Which applications? And is the C version going to disappear, requiring all users to

Re: [OT] Moving to a RTOS on the RP2040

On Thu, Jul 4, 2024 at 7:19 PM Gregory Nutt wrote: > > On 7/4/2024 4:44 PM, Alan C. Assis wrote: > > I think Greg avoided using submodules because there are many issues > caused > > by it. > > > > In fact submodules could avoid this issue, but maybe we could have some > > marks indicating the las

Re: [OT] Moving to a RTOS on the RP2040

On Thu, Jul 4, 2024 at 5:21 PM Alan C. Assis wrote: > Nice post for a guy (apparently with previous Linux experience, that type > of person normally find their way well on NuttX) moving from baremetal to > RTOS: > > https://blog.brixit.nl/moving-to-a-rtos-on-the-rp2040/ > > The issue he commented

Re: Creating a NuttX mirror for external files

On Thu, Jun 27, 2024 at 12:45 PM Alin Jerpelea wrote: > All those projects have to be kept in sync with the upstream which may > create some extra work > I am a bit concerned for the maintenance effort > > Best regards > Alin Can it be some kind of a mirror that automatically syncs to upstream

Re: Creating a NuttX mirror for external files

On Thu, Jun 27, 2024 at 11:40 AM Gregory Nutt wrote: > On 6/27/2024 9:30 AM, Tomek CEDRO wrote: > > Hey there Alan :-) > > > > +1 here :-) > > > > I would put that to apache/nuttx-deps repo so maintenance is easier > > and more coherent with the rest of the project :-) > > > > Have a good day fol

  1   2   3   4   5   6   7   8   9   10   >