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