1) More opinionated documentation
a) In particular clear instructions:
– where to get compilers for C/C++
– how to setup project with an application outside of nuttx, and clear
[apps], [libs], [board], [nuttx] structure
– how to set up your own board
These questions are recurring. They were asked on the mailing list recently
again. They are basic things and they should be the second page of
documentation.
b) Typical policy for documentation is that when people ask, the answer
should be put to documentation and the link sent back as an answer.
c) Table of supported features on different platforms and boards, as
discussed recently. For people who want to use NuttX to feel safe and know
how much they need to contribute to make their project work.
2) Package management
Database where people can submit whatever they want, as long as it works
and they are willing to maintain it.
Description on what such packages need to fulfill to work with NuttX. Some
simple command line tool to inject packages to NuttX projects.
Am Mi., 5. Aug. 2020 um 17:20 Uhr schrieb Xiang Xiao <
xiaoxiang781...@gmail.com>:
> I would see the automation test on the roadmap, thanks.
>
> > -----Original Message-----
> > From: Matias N. <mat...@imap.cc>
> > Sent: Wednesday, August 5, 2020 4:59 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: Roadmap?
> >
> > Having a (public) roadmap is very good idea, it guides and organizes
> efforts over time and also gives indication to existing or
> potential
> > users about which features which are not currently but might as well be
> there soon.
> >
> > I personally would like to see support for Bluetooth/WiFi on widely used
> hardware platforms.
> > I'm currently working on getting BLE on nRF working so it is a matter of
> time. I hope that also Alan might steer Espressif into
> add
> > support for ESP32. LoRaWAN stack would also be interesting.
> > I would also add the current documentation effort as part of the roadmap.
> >
> > I think with a Roadmap laid out it would be possible to create GitHub
> milestones (major and minor) and organize issues into each,
> > depending on how disruptive the change is. This would help to have for
> example a 10.x series more or less stable while holding
> bigger
> > changes towards 11.0 or even 12.0.
> >
> > Just my two cents.
> >
> > Best,
> > Matias
> >
> > On Tue, Aug 4, 2020, at 17:32, Gregory Nutt wrote:
> > > One of the things that I think we are missing is a Roadmap to guide
> > > and prioritize new feature development. Other RTOS' (like Zephyr) do
> > > have such published roadmaps and are responsive to needs and requests
> > > of users and sponsors. I have even seen web pages where the Zephyr
> > > team has laid out what new features on the roadmap will be available
> > > in future releases.
> > >
> > > While I think it would be essentially impossible for us to manage such
> > > a thing with our loose organiation, I think we should have a roadmap
> > > that identifies the important directions that operating system will
> take.
> > >
> > > For me, the important thing is to stay relevant and contemporary and
> > > not get lost in some aging niche architecture or toolset. I think
> > > that the best way to predict where NuttX needs to be is to look at the
> > > SoCs in use just above the upper end of the NuttX market. I think
> > > over time, those features will trickle down into embedded systems
> > > (albeit with some twists and modifications for the embedded market).
> > > The Cortex-M7 introduces I-Cache and L1 D-Cache, for example. A few
> > > years ago, those were higher end features not available on MCUs.
> > >
> > > I think that SMP and AMP are key technologies to get us a leg up on
> > > future mutli-core MCUs. KERNEL mode places us in a position to
> > > support MCUs with MMUs. A proper TrustZone model for all ARM parts is
> > > needed too (the multi-core TrustZone model is pretty well in place,
> > > but what do we do with TrustZone on a single CPU?).
> > >
> > > Security, especially IoT security is very important. Some security
> > > topics are addressed by PROTECTED mode. So although PROTECTED and
> > > KERNEL build modes are not commonly used, I believe that they are
> > > important parts of the roadmap.
> > >
> > > Other thoughts? We should collaborate and define a meaningful
> > > roadmap that will keep the OS healthy well into the future. We should
> > > publish that roadmap somewhere so that anyone can see where we are
> > > going and can offer insights for other directions.
> > >
> > >
> > >
>
>
