Re: Hold off merging PRs
On Sun, Jun 14, 2020 at 11:04 PM spudaneco wrote: > I see a few new PRs coming in. I want to remind everyone that tomorrow we > plan the branch for release/9.1. If committers could hold off merging > until that branch is in place, the I think we have a chance for a good > release candidate!Thanks! Then, after the branch , if any merges cause > issues, we will have another two months to find and fix them.GregSent from > Samsung tablet. Yes. Agreed. I think the code we have in master right now will make a good release candidate. Much has happened since 9.0 and it seems that things have stabilized pretty well in the last week or so. Thanks for the reminder and thanks to everyone for all your hard work!! Nathan
Hold off merging PRs
I see a few new PRs coming in. I want to remind everyone that tomorrow we plan the branch for release/9.1. If committers could hold off merging until that branch is in place, the I think we have a chance for a good release candidate!Thanks! Then, after the branch , if any merges cause issues, we will have another two months to find and fix them.GregSent from Samsung tablet.
Re: NXView
Hi Erdem, Right, I understood your idea! In fact Maciej already created it, see: https://hackaday.io/project/94372-upm-nuttx-project-manager https://gitlab.com/w8jcik/upm Did you try it? BR, Alan On 6/14/20, Erdem MEYDANLI wrote: > Hi Alan, > > > You are right. NuttX has a more comprehensive scope. For sure, what I > proposed requires a lot of work. > > > With or without OpenOCD, what I meant by SDK was a combination of (actively > maintained) buildroot and a meta-tool like *West *in Zephyr. > > > Those who haven't heard of Zephyr's meta-tool might want to look at this: > https://docs.zephyrproject.org/latest/guides/west/build-flash-debug.html > > > I assume that the 'SDK' solves all dependency issues, and the meta-tool > offers the functionality below: > > > nxtool flash > > nxtool debug > > nxtool monitor (imagine this initiates @Greg's idea as part of its > functionality.) > > > People who are already familiar with RTOSes and MCU development undoubtedly > follow the current installation steps quickly. Maybe they already > established a mini-automation for their development process. However, when > it comes to beginners, the installation can still be a pain in the neck. > > > So, this discussion is about the unborn NXView, and I don't want to ramble > on about it. I find the NXView idea very beneficial. And referring to > Greg's paragraph below, having a meta-tool that I try to explain above > might add significant value as well. > >>> > I believe that such a tool would be a valuable addition to the NuttX > ecology. I think that such a tool would move NuttX from a basic, > primitive open source OS project and into full competition with > commercial products (in terms of features and usage... we are not > actually in competition with anyone). > << > > > Alan Carvalho de Assis , 14 Haz 2020 Paz, 18:51 > tarihinde şunu yazdı: > >> Hi Erdem, >> >> On 6/14/20, Erdem MEYDANLI wrote: >> sic >> > >> > I do agree. That would be such an invaluable tool. BTW, speaking of >> > particular hardware like FT245 gives me an idea. Well, this might sound >> > a >> > little bit irrelevant, but what about taking it a step further and >> > developing a mini-SDK (NX-SDK) as the one Zephyr has? Still not as a >> > very >> > active contributor, but an enthusiastic follower of the NuttX project, >> > I >> > think that the entry barrier of the project is still not that low. >> > Onboarding takes some time. Having a custom SDK that includes not only >> > a >> > tracer, but also other helper tools (e.g., flasher/debugger for the >> > supported boards) would facilitate the adaptation process of the >> newcomers. >> > Finally, rather than relying on some particular ICs, would it be more >> > practical to build such a tool by creating a (custom) fork of OpenOCD? >> > >> >> In the past NuttX used to have a Buildroot that was able to generate >> the toolchain, etc. It is still around, some time ago David Alessio >> fixed it. >> >> At first place the SDK idea appears good, but there are many issues. >> >> We have many architectures, we support MCU/CPU from 8 to 64-bit >> (Zephyr and others are 32-bit only and mainly ARM, RISC-V and Xtensa). >> I could go on citing other issues... >> >> Currently at least on Linux (Debian, Ubuntu, ...) and Ubuntu Shell on >> Windows it is very easy, just some apt/apt-get away. Even the >> kfrontend is already there, you don't need to compile it anymore. I >> think the main issue is that OpenOCD version is too old. But creating >> a fork of OpenOCD is not a good idea. >> >> OpenOCD is a project that deserves more attention, it is like the SSH, >> many people/companies uses it and people only not it was a "backbone" >> when it broke. >> The last OpenOCD release was 3 years ago and I don't see any move to a >> new release. If they release a new version now, maybe it will delay >> about 2 years to get it officially on Linux distros. >> >> I heard that OpenOCD was going to be part of Linux Foundation, but >> nothing happened yet. Let see! >> >> BR, >> >> Alan >> >
Re: NXView
Hi Alan, You are right. NuttX has a more comprehensive scope. For sure, what I proposed requires a lot of work. With or without OpenOCD, what I meant by SDK was a combination of (actively maintained) buildroot and a meta-tool like *West *in Zephyr. Those who haven't heard of Zephyr's meta-tool might want to look at this: https://docs.zephyrproject.org/latest/guides/west/build-flash-debug.html I assume that the 'SDK' solves all dependency issues, and the meta-tool offers the functionality below: nxtool flash nxtool debug nxtool monitor (imagine this initiates @Greg's idea as part of its functionality.) People who are already familiar with RTOSes and MCU development undoubtedly follow the current installation steps quickly. Maybe they already established a mini-automation for their development process. However, when it comes to beginners, the installation can still be a pain in the neck. So, this discussion is about the unborn NXView, and I don't want to ramble on about it. I find the NXView idea very beneficial. And referring to Greg's paragraph below, having a meta-tool that I try to explain above might add significant value as well. >> I believe that such a tool would be a valuable addition to the NuttX ecology. I think that such a tool would move NuttX from a basic, primitive open source OS project and into full competition with commercial products (in terms of features and usage... we are not actually in competition with anyone). << Alan Carvalho de Assis , 14 Haz 2020 Paz, 18:51 tarihinde şunu yazdı: > Hi Erdem, > > On 6/14/20, Erdem MEYDANLI wrote: > sic > > > > I do agree. That would be such an invaluable tool. BTW, speaking of > > particular hardware like FT245 gives me an idea. Well, this might sound a > > little bit irrelevant, but what about taking it a step further and > > developing a mini-SDK (NX-SDK) as the one Zephyr has? Still not as a very > > active contributor, but an enthusiastic follower of the NuttX project, I > > think that the entry barrier of the project is still not that low. > > Onboarding takes some time. Having a custom SDK that includes not only a > > tracer, but also other helper tools (e.g., flasher/debugger for the > > supported boards) would facilitate the adaptation process of the > newcomers. > > Finally, rather than relying on some particular ICs, would it be more > > practical to build such a tool by creating a (custom) fork of OpenOCD? > > > > In the past NuttX used to have a Buildroot that was able to generate > the toolchain, etc. It is still around, some time ago David Alessio > fixed it. > > At first place the SDK idea appears good, but there are many issues. > > We have many architectures, we support MCU/CPU from 8 to 64-bit > (Zephyr and others are 32-bit only and mainly ARM, RISC-V and Xtensa). > I could go on citing other issues... > > Currently at least on Linux (Debian, Ubuntu, ...) and Ubuntu Shell on > Windows it is very easy, just some apt/apt-get away. Even the > kfrontend is already there, you don't need to compile it anymore. I > think the main issue is that OpenOCD version is too old. But creating > a fork of OpenOCD is not a good idea. > > OpenOCD is a project that deserves more attention, it is like the SSH, > many people/companies uses it and people only not it was a "backbone" > when it broke. > The last OpenOCD release was 3 years ago and I don't see any move to a > new release. If they release a new version now, maybe it will delay > about 2 years to get it officially on Linux distros. > > I heard that OpenOCD was going to be part of Linux Foundation, but > nothing happened yet. Let see! > > BR, > > Alan >
Re: NXView
In the past NuttX used to have a Buildroot that was able to generate the toolchain, etc. It is still around, some time ago David Alessio fixed it. It generates more than that. It generates most of the tools that you need including kconfig-frontends, genromfs, etc. And it is easily extended to include more host tools. It is 90% of an SDK, depending on how you define an SDK. It can never be a part of the Apache NuttX project, however, since most of the tools are GPL. If someone wants to take over the build root and expand on it, we can do that.
Re: [nuttx] Re: NXView
You sucked me in. It was only $8 to get one here tomorrow... and I am not sure I can find another use for it even if this does not work out. For those following along, you can find the board I am talking about on ebay, amazon, etc.. by looking for "EX-USB FX2LP" I ordered a couple of those from China too. But I won't get them here in Costa Rica until August. Looks like you will be the trailblazer.
Re: NXView
Hi Erdem, On 6/14/20, Erdem MEYDANLI wrote: sic > > I do agree. That would be such an invaluable tool. BTW, speaking of > particular hardware like FT245 gives me an idea. Well, this might sound a > little bit irrelevant, but what about taking it a step further and > developing a mini-SDK (NX-SDK) as the one Zephyr has? Still not as a very > active contributor, but an enthusiastic follower of the NuttX project, I > think that the entry barrier of the project is still not that low. > Onboarding takes some time. Having a custom SDK that includes not only a > tracer, but also other helper tools (e.g., flasher/debugger for the > supported boards) would facilitate the adaptation process of the newcomers. > Finally, rather than relying on some particular ICs, would it be more > practical to build such a tool by creating a (custom) fork of OpenOCD? > In the past NuttX used to have a Buildroot that was able to generate the toolchain, etc. It is still around, some time ago David Alessio fixed it. At first place the SDK idea appears good, but there are many issues. We have many architectures, we support MCU/CPU from 8 to 64-bit (Zephyr and others are 32-bit only and mainly ARM, RISC-V and Xtensa). I could go on citing other issues... Currently at least on Linux (Debian, Ubuntu, ...) and Ubuntu Shell on Windows it is very easy, just some apt/apt-get away. Even the kfrontend is already there, you don't need to compile it anymore. I think the main issue is that OpenOCD version is too old. But creating a fork of OpenOCD is not a good idea. OpenOCD is a project that deserves more attention, it is like the SSH, many people/companies uses it and people only not it was a "backbone" when it broke. The last OpenOCD release was 3 years ago and I don't see any move to a new release. If they release a new version now, maybe it will delay about 2 years to get it officially on Linux distros. I heard that OpenOCD was going to be part of Linux Foundation, but nothing happened yet. Let see! BR, Alan
NuttX Online Workshop
Hi Everybody, I hope you are fine and safe! As you probably know the NuttX 2020 Workshop Japan was cancelled because COVID-19. So, we are planing the NuttX Workshop (this time online) to Aug 15-16 2020. If you like to present about some project powered by NuttX, please subscribe to workshop list: workshop-subscr...@nuttx.apache.org and submit your proposal. Those who have already submitted a proposal to NuttX 2020 Japan and want to submit it, send me a private email. BR, Alan
Re: NXView
> I would think that such an application would be a C++ development and would be usable both on Windows and Linux. << Would it be nice to have an application that utilizes HTML5 and CSS3 for the UI, communicates with the low-level parts of the app via WebSockets? (Lesser C++, but additionally some JS.) > I believe that such a tool would be a valuable addition to the NuttX ecology. < I do agree. That would be such an invaluable tool. BTW, speaking of particular hardware like FT245 gives me an idea. Well, this might sound a little bit irrelevant, but what about taking it a step further and developing a mini-SDK (NX-SDK) as the one Zephyr has? Still not as a very active contributor, but an enthusiastic follower of the NuttX project, I think that the entry barrier of the project is still not that low. Onboarding takes some time. Having a custom SDK that includes not only a tracer, but also other helper tools (e.g., flasher/debugger for the supported boards) would facilitate the adaptation process of the newcomers. Finally, rather than relying on some particular ICs, would it be more practical to build such a tool by creating a (custom) fork of OpenOCD? Erdem Gregory Nutt , 13 Haz 2020 Cmt, 02:02 tarihinde şunu yazdı: > Hi, List, > > I have been contemplating a NuttX-based Open Source project today and I > am interested in seeing if anyone is willing to participate or, even if > not, if anyone has any insights or recommendations that could be useful. > > Basically, I am thinking of a NuttX tool to monitor the internal state > of the OS. This would be conceptually similar to Segger SystemView or > Wind River WindView: A host basic graphical tool that exposes the > internal behavior of tasks and threads within the OS in a "logic > analyzer format": > > 1. Horizontal rows would be indicate the state of each task, running or > block (and if blocked why/) > 2. Each arranged vertically by task/thread priority so that the highest > priority task is the first row and the lowest priority task is the > bottom row. > 3. Annotation to indicated events: Interrupts, semaphore operations, > spinlock operations, etc. > 4. This display should be realtime (with a lag, of course) and should > scroll to the right as time elapses. It should be possible to > capture and save the event data for subsequent offline analysis. > > Additional analytic displays could be considered in the future. > > The hardware I am thinking to accomplish this would be an inexpensive > FT245RL board which connects to the target via an 8-bit parallel > interface and to the host via a USB 2.0 interface. The target side is > essentially a FIFO: OS events would be written to the FT245RL FIFO and > transferred to the host via USB 2.0. > > The OS instrumentation is already in place to accomplish this. This is > controlled by CONFIG_SCHED_INSTRUMENTATION and related configuration > options that you can see in sched/Kconfig. The target side effort is then: > > 1. Configure the parallel interface to the FT245RL's FIFO. This would > likely be FSMC for an initial STM32 implementation. > 2. Develop the simple logic to encode the instrumented events and to > pass them to host visa that FIFO. > > Drivers and configuration tools for the host side are already available > from the FTDI website. Becoming familiar with these tools and > integrating the host-side interface would be another task. > > The final task, the one that is the most daunting to me, is the > development of the substantial host-side graphics application that would > receive the OS instrumentation data and produce the graphic > presentation. I would think that such an application would be a C++ > development and would be usable both on Windows and Linux. > > I believe that such a tool would be a valuable addition to the NuttX > ecology. I think that such a tool would move NuttX from a basic, > primitive open source OS project and into full competition with > commercial products (in terms of features and usage... we are not > actually in competition with anyone). > > Is this something that would be interesting to anyone? Does anyone have > any input or advice? If there is any interest I think that we should > create a small development team to make this happen. If that team is > small enough, I would be happy to provide common development hardware > (STM32 and FT245RL boards from China, or course). > > What say ye? > > Greg > >
