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. > > > > > > > > > > > > > > > > > > > > > > > >
