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 <acas...@gmail.com>, 14 Haz 2020 Paz, 18:51 tarihinde şunu yazdı: > Hi Erdem, > > On 6/14/20, Erdem MEYDANLI <emeyda...@gmail.com> 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 >
