Folks, I made a wiki page with the raw list of things that people are asking for in this thread:
https://cwiki.apache.org/confluence/display/NUTTX/Roadmap Check it out, add anything I missed, and correct errors I made. Maybe the next step would be to try to complete this list, then maybe prioritize it, connecting it with releases and the things people have energy working on and collaborating together on? If what you want to put here doesn't fit on the page, make a child page. :) cheers adam On Wed, Aug 12, 2020 at 9:52 AM Alan Carvalho de Assis <acas...@gmail.com> wrote: > Hi Matous, > > Did you see this CANopen implementation: > > https://github.com/rscada/libcanopen > > Now it should be easy to use because NuttX supports SocketCAN. > > BR, > > Alan > > On 8/12/20, Matous Pokorny <matous.pokorny@datavision.software> 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. > >> > > > > > >> > > > > > >> > > > > > >> > > > >> > > > >> > > >> > > > -- Adam Feuer <a...@starcat.io>
