On Wed, Mar 8, 2023 at 11:14 PM Nathan Hartman wrote: > On Wed, Mar 8, 2023 at 4:02 PM Sebastien Lorquet <sebast...@lorquet.fr> > wrote: > > You are right about posix compliance, this is a valuable goal, but at > > the same time it raises the hard remark: > > At some point NuttX will grow too large for deep embedded platforms. > > My concern exactly. Yes, POSIX compliance is super important because it > provides portability: I regularly write a program and run it on PC and > embedded with almost no changes. This is one of the big selling points of > NuttX for me. > > At the same time, there's another kind of portability: between MCU models > and families. Before NuttX if I had a firmware running perfectly on PIC32 > and wanted to move it to Tiva I had to rewrite everything. NuttX support > for many MCU models eliminates this (except the occasional bugfix in low > level driver code or something). That's a huge advantage. Supporting lots > of architectures means the next project is likely to find one that will > work. > > If we won't fit on the smaller micros, we'll lose some of that advantage. > Maybe it doesn't matter. Maybe the days of super small MCUs are numbered > and things are moving to bigger flash, 64-bit, and Raspberry Pi class > embedded systems. Maybe that's okay. But, if that's the direction to go, > then we just need to be clear about what our future holds so that users > won't build designs around micros that are not going to be supported for > much longer.
Well for me this is the biggest advantage of NuttX over other RTOS! It is advertised as working on 8-bit CPU/MCU upwards and it would be really nice that things stayed that way. I would love to port NuttX one day to MC68000 and MOS6502. Probably others will also switch to NuttX because of that scalability. Loosing that will cause NuttX loose its strongest point. Why not stay with microkernel that can fit into kilobytes of flash and ram and keep all other stuff into module / library / application layer? That way extreme scalability would be maintained and new features could show up with no conflict? For instance, lets take old Atari, or other MCU, with 64KB of RAM and similar (possibly smaller) Flash size. Kernel + custom application would fit in. Data can be provided in a raw form. Additional processing can be done by additional optional application/module/library at the cost of required memory. Additional processing can be easily done by external machine / platform (i.e. terminal application on a pc). But if we want to add a web server then more powerful MCU and/or additional memory is required. Still it would be possible to fit core functionality on a tiny MCU. Worst case (?) is when we have tiny kernel and all required functionalities (provided with libraries) are packed into application that determines memory requirements for the hardware. I guess this is most common approach in RTOS anyway? > Maybe, like FreeBSD, we should declare support "tiers" for different > architectures and MCUs, with Tier 1 meaning supported fully and other tiers > for things like partial support (experimental?) or deprecated... just a > thought. This is a very nice idea that would extend current Supported Platforms [1] to know what is the actual status of the hardware support at first glance. I like to know things at first glance. This would not really introduce any new bonds or obligations but provide better insight for the potential (new) users :-) [1] list on https://nuttx.apache.org/docs/latest/introduction/supported_platforms.html -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
