Should we start creating issues for these ideas and start assigning them to milestones? The initial milestone could be "future" so that we can later decide on a given version to target.
On Wed, Aug 12, 2020, at 13:03, Matous Pokorny wrote: > Hello! > > I definitely agree with all the words written below and I would like to add > few wishes. > > I am interested in industrial devices communicating by fieldbuses. I use > the NuttX port of FreeModbus stack and I would like to see more port of > communication stacks like this. I prefer CANopen and Profinet, There are > several open source communication stack for these protocols. > > Thank you and have a nice day. > _____________________________ > *Matouš Pokorný* | Embedded system developer > DataVision s.r.o. | Czech Republic > > st 5. 8. 2020 v 18:48 odesílatel Matias N. <mat...@imap.cc> napsal: > > > On Wed, Aug 5, 2020, at 13:35, Maciej Wójcik wrote: > > > 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. > > > > Completely agree on the above. I would add that when people add a new > > board they document it > > following a set of guidelines (maybe based on a template). Also, new > > features or breaking changes > > should be accompanied by documentation changes. Distributing the load on > > maintaining the documentation > > IMHO is the way to keep it updated. > > > > > 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. > > > > On my "NuttX workspace manager" ( > > https://gitlab.com/nuttx_projects/nuttx_workspace_manager) I have this > > mechanism that allows you to simply drop a directory containing an app > > inside an "extra_apps" directory. This works > > by having a symlink from apps/external point to this directory, where > > NuttX looks for external apps. The trick is to > > have a Make.defs recursively including Make.defs from subdirectories and a > > Makefile including "Directory.mk". This are the files that are placed > > inside extra_apps/: > > https://gitlab.com/nuttx_projects/nuttx_workspace_manager/-/tree/master/files/extra_apps. > > If external/ would already have this set up, it would indeed be a matter of > > dropping an app there. > > > > Furthermore, I personally like to use submodules but even if you simply > > clone or download a git repo containing just the app, you wouldn't need a > > central database of apps, just a git repo for each app. If some sort of > > "central repository" is desired, a special github organization could be > > used to collect contributed apps. > > > > I have a similar mechanism for OS level code, which is compiled as if it > > were a subdirectory of nuttx/. > > > > Best, > > Matias > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
