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

Re: Integrating port specific syscall proxies

On Wed, May 29, 2024 at 9:50 AM Gregory Nutt wrote: > On 5/29/2024 6:10 AM, Nathan Hartman wrote: > > That's a security hole in the *hardware*, not in software, right? How can > > that be fixed (unless a new chip is made)? > > No, software. > > Disclaimer: I don

Re: Integrating port specific syscall proxies

On Tue, May 28, 2024 at 10:07 AM Gregory Nutt wrote: > On 5/26/2024 5:03 PM, Stuart Ianna wrote: > > With the riscv/litex port, we're able to access the TIME and TIMEH CSRs > in > > usermode. I would like to take advantage of this feature to replace the > > proxies for syscalls, such as timer_get

Re: NAND Flash supported Board suggestion

On Sat, May 25, 2024 at 8:58 PM Gregory Nutt wrote: > > Seems like dhara.c was integrated into mainline, but they didn't submit > > support to YAFFS (if I remember correctly it was because YAFFS requires > > license payment for commercial usage). > > There no references to either under fs/. > > T

Re: Does Nuttx support hard real time?

On Fri, May 17, 2024 at 1:42 AM 吳岱儒 wrote: > Hi community, > > Is Nuttx a hard real time RTOS or software RTOS? > If Nuttx support hard real time, is there any documentation about this > feature and design ? > > BRs, > TaiJuWu > Hello, It depends on the CPU architecture: For example, on ARM Co

Re: Missing bytes on serial port

When writing to the port, write() should indicate number of bytes written. Are you checking the return value and is it less than expected? Note that write() enqueues the bytes but returns before write complete. If port is closed before hardware finishes shifting all the bits out, message will be t

Re: Missing bytes on serial port

On Thu, May 9, 2024 at 3:31 AM Mark Stevens wrote: > So we have a two chip board: > > * STM32 running NuttX (v7.5 I believe) > * ESP32 acting as a coprocessor running custom firmware > > The STM32 runs the show and the ESP32 provides services to the STM32 code. > > In normal run mode, NuttX has a

Re: Beginner questions

On Sun, Apr 28, 2024 at 1:45 AM M. Edward (Ed) Borasky < zn...@algocompsynth.com> wrote: > I've just run across NuttX, and I think it's a good fit for my project. > What I'm trying to do is develop some computer music applications on > microcontrollers. I'm mostly interested in the Raspberry Pi Pi

Re: ESP32 (classic) RAM size question

I recommend to add a comment there, to explain that although the board has 320KB in total, ~200KB is used for WiFi and BLE. On Thu, Apr 25, 2024 at 8:36 PM Alan C. Assis wrote: > Hi Bernd, > > You can use 320KB only if you don't need to use WiFi and BLE. > > The memory is used but the WiFi/BLE d

Re: Options to contribute to NuttX without github?

Even if the NuttX PMC requested to opt-out from "The Stack" there could be (and probably are) a million other stacks, and many of those might be quite a bit less transparent about what they're doing. So, like I said before, all our code is public and there's not much we can do to prevent AIs from t

Re: Options to contribute to NuttX without github?

For those who cannot or don't want to access GitHub, the gitbox repos on ASF infrastructure are actually the "real" source of truth. As I understand it, our GitHub repos are really some kind of mirror that is kept in a two-way sync with gitbox. (Unless something has changed since I last looked into

Re: Rust in the OS?

tl;dr: I am in wait-and-see mode regarding Rust. The long story: I have been watching the programming language landscape for some time to see if there is a viable successor to C/C++. C has many advantages: * Standardized (ISO and ANSI standards) since more than 30 years ago, which makes the lan

Re: Re:Re: mm/mm_heap assertion error

/github.com/yf13/hello/tree/debug-logs/nsh-rpmsgfs . There are two > sets from two ELFs created from same code base but with different DEBUG _xx > configs.  The crash happens earlier in the build with more debug > options. > > > Please let me know if you have any more suggestions. &

Re: mm/mm_heap assertion error

What's needed is some way to binary search where the culprit is. If I understand correctly, it looks like the crash is happening in the later stages of board bring-up? What is running before that? Can parts be disabled or skipped to see if the problem goes away? Another idea is to try running a s

Re: Ethernet direct RMII connection

RMII just means it uses fewer I/O pins from the MCU as compared to MII. I don't remember the details either but it's possible that some chips support RMII and not MII because they don't have the additional I/O pins. Tiva-C (arch/arm/src/tiva) supports RMII (the chip has the built-in MAC and PHY) s

  1   2   3   4   5   6   7   8   9   10   >