Hi Grr, I agree with many points you raised: the amount of options inside NuttX menuconfig is really a bad thing, it is like a maze. You need to track many configs until you get everything in place and get things done. But in the other hand it is what let you to fine tune the system for your need.
It was implemented this way because of the modularity, flexibility and customization level offered by NuttX. When you select that you want Network support the configuration don't try to "read or mind" and enable TCP or other protocol. You need to connect all the points. I think raising these issues is really valid and helps to realize the issue. About SPI, the solution you suggested was interesting, but as I recall it was not easy to implement. I requires creating many pins options inside the menuconfig, also it requires some external tool that you develop, if I recall correct. I think the best approve for NuttX is gaining support to Device Tree, like the existent for Zephyr. Many of the issues related to board configuration for devices that uses I2C and SPI can be fixed using the "common board" approach, but it needs to be fixed for all boards and as you know we don't have many people helping. BR, Alan On 8/6/21, Grr <gebbe...@gmail.com> wrote: > El mar, 3 ago 2021 a las 6:49, Alan Carvalho de Assis (<acas...@gmail.com>) > escribió: > >> Unfortunately NuttX is not for faint of heart people (same to the >> Linux kernel) > > I don't know about Linux but what makes NuttX not for the faint of heart is > you, the core programmers. I explain why: > > *Config Nightmare* > NuttX menuconfig is a minefield. The first time I tried to test NuttX, > selecting desired options caused a compilation crash because there are a > lot of broken combinations (I fixed 4 or 5 to flex my muscles), especially > regarding networking. When I *repeatedly* talked about making it easier for > newbies, nobody even blinked and when I came with a GPIO subsystem that > allows easy configuration via menuconfig, you showed complete lack of > interest > > *Balkanization* > Device support in NuttX is ludicrous. If I want to connect an SPI device > like MCP2515 to a *supported random board*, I have to port the driver > because the existing driver is tied to Blue Pill and one or two other > boards. As anyone understands, a supported SPI peripheral *should* work > with *any* supported board because a driver should work at bus level, *not* > board level. If I'm a newbie that doesn't want or can go that deep, I'm SOL > > *Double Standards* > I tried to correct the situation and developed a new SPI subsystem that > doesn't tie drivers to a specific board, just to clash into header file > mess: with the excuse of modularity, header files are mixed with source > files, making it very difficult (I suspect on purpose) to build a > board-agnostic driver system > > Of course, modularity is something for *others* to observe. The leader can > enforce modularity and at the same time recommend to use internal > interfaces when needed ( > https://www.mail-archive.com/dev@nuttx.apache.org/msg05752.html) > > *Networking Phobia* > Back in 2015, I asked about SocketCAN on NuttX ( > https://nuttx.yahoogroups.narkive.com/RMKDgEcn/canopen-stack) but Nutt > didn't want to even hear about it and *ERASED MY QUESTIONS FROM NEWSGROUP*. > Five years later, Nutt was deploring that SocketCAN port to NuttX was > rusting in a branch. And this schizophrenic attitude towards networking > shows in NuttX > > In sum, it's not that NuttX is hard. It's that *NuttX IS MADE HARD, > PROBABLY ON PURPOSE* > > In that scenario, Robert's position is perfectly understandable and even > advisable. I myself will follow suit and go to a better RTOS, where I don't > have to fight against everything to get the work done. I've wasted enough > time > > Good bye > > >> I know you are not an stupid guy and you have great >> projects under your belt, but think also about your attitudes here. >> Read again all the complains you did in your emails and imagine the >> other side of your computer are few guys that spend years of their >> life making that code. >> >> BR, >> >> Alan >> >> On 8/3/21, Robert Lipe <robertl...@gmail.com> wrote: >> > This iteration of BeagleV hardware is canceled <https://beaglev.org/>. >> > Given the friction of landing PR#3965, I'm just going to abandon it and >> > mark that CL closed and will be unsubscribing from the lists. There's >> > probably nothing worth heroic efforts to preserve; only a few of those >> 108 >> > commits were real work with the rest just feeding the machine. That >> > basic >> > PR will be needed by the likes of SiFive Unmatched and other RISC-V >> > hardware. >> > >> > The NuttX tech is interesting, but I spent an unreasonable amount of >> > time >> > chasing ghosts in the build system and the culture. A style guide >> > that's >> so >> > complex that you can't teach it to a machine and blocking submits >> > because >> > unrelated files have C99 comments inside an embedded string is just not >> > a >> > fit for me. >> > >> > Thanx to those of you that genuinely tried to help onboard a new dev. >> Good >> > luck to the project on your journey to be accepted by Apache. >> > >> > RJL >> > >> > On Wed, Jun 23, 2021 at 10:03 AM Abdelatif Guettouche < >> > abdelatif.guettou...@gmail.com> wrote: >> > >> >> *So I've kicked that back in, but it appears I have to wait for a >> >> (gasp)human**to push a button*. >> >> >> >> This is actually a Github thing and is outside of our control. It's >> >> pretty >> >> new too, so we too have to get used to it. As Nathan said, this only >> >> applies to first time contributors. Subsequent contributions should >> >> go >> a >> >> bit smoother. >> >> >> >> On Wed, Jun 23, 2021, 3:37 PM Nathan Hartman >> >> <hartman.nat...@gmail.com> >> >> wrote: >> >> >> >> > On Tue, Jun 22, 2021 at 11:12 PM Robert Lipe <robertl...@gmail.com> >> >> wrote: >> >> > >> >> > > > >> >> > > > >> >> > > > > The presubmit flips out about C99 comments. Even that's too >> >> radical. >> >> > So >> >> > > > > much for being king. :-) >> >> > > > >> >> > > > You can use C99, but you cannot forgot to follow the Coding >> >> > > > Style, >> >> > > > // >> >> > > > comments shouldn't be used :-) >> >> > > > >> >> > > >> >> > > It's actually worse than that. You can use C99 comments at the end >> of >> >> > > a >> >> > > line >> >> > > but not at the beginning >> >> > > >> >> > > frobnicate(); // this is accepted >> >> > > // this is an error >> >> > >> >> > >> >> > That is a bug in nxstyle.c and should be fixed. Please file an issue >> >> > or, >> >> if >> >> > you're inclined, open a PR... >> >> > >> >> > This is perfectly legal C99. That's 20+ years ago and was widely >> >> > accepted >> >> > > before then. >> >> > >> >> > >> >> > That's true; however this standard and code style are well >> >> > established >> >> > in >> >> > this project; of course anyone can feel free to open a [DISCUSS] >> thread >> >> to >> >> > propose changes but the onus is obviously on them to persuade the >> >> community >> >> > why it should make those changes. >> >> > >> >> > I see // comments in 48 *.[ch] files. That ship has sailed. >> >> > >> >> > >> >> > That, too, is a bug and should be fixed. >> >> > >> >> > So I've kicked that back in, but it appears I have to wait for a >> (gasp) >> >> > > human >> >> > > to push a button. I assume this is to stop script kiddies from >> >> submitting >> >> > > bitcoin >> >> > > harvesters in the presubmit, but it really hoses a workflow as >> >> > > it's >> >> like >> >> > > submitting >> >> > > a box of punched cards across the table into the Holy Room where >> >> > computing >> >> > > is done and then awaiting a stack of greenbar with the results >> >> > > later >> >> > > in >> >> > the >> >> > > day. >> >> > >> >> > >> >> > Yes, it's to stop script kiddies with their mining businesses; >> >> > however >> >> IIRC >> >> > that only applies to your first PR with a project. I think once your >> PR >> >> > gets merged the next one will go more swiftly. >> >> > >> >> > Hopefully, you're convinced I'm an actual human at this point (even >> >> > if >> >> > I >> >> > > complain >> >> > > too much :-) >> >> > >> >> > >> >> > Nope. I'm not convinced. :-p >> >> > >> >> > Jokes aside your participation is greatly appreciated. >> >> > >> >> > Cheers, >> >> > Nathan >> >> > >> >> >> > >> >
