Re: Move to C99 for common code
Hi, SDCC recently added a 6502 port, based on their HC08 port. I think it has a chance to be better than cc65 or any gcc arsenal. Yes, the 6502 8-bit hardware stack is very limited, but by paying the price of a less efficient code, a software stack is possible. Of course, such a port would probably be EXTREMELY limited and possiby just a proof of concept, but a fun one for sure. Speaking of the Z80, would it be possible to run NuttX in a Grant Searle / RC2014 platform with a 8k ROM /56k RAM split, or would any attempt require banked memory? I appreciate this discussion about protecting the NuttX supported platforms. So many RTOS are just for arm. Sebastien Le 08/01/2022 à 15:46, Alan Carvalho de Assis a écrit : Yes, now I remember the reason to it has been removed. BTW, I think 6502 will face same issue because the stack point is only 8-bits (it will be limited to 256 bytes), correct? On 1/8/22, Gregory Nutt wrote: Support for the 8051 was removed for other reasons... that family has a very small hardware stack that had to be saved and restored on each context switch. That provided bigtime compatibility issues with other architectures. That combined with the facts that (1) I never could get the 8051 running reliably without stack overflows, and (2) the 8051 was not really a viable platform for NuttX because it was so limited in other ways. That is ancient history from 2014. I used to carefully document why any feature was removed from the OS and kept that here: https://bitbucket.org/patacongo/obsoleted/src/60ec01456d8b09f5b813a5fd8865cdbd5a0ccc20/ChangeLog#lines-4 On Sat, Jan 8, 2022 at 7:45 AM Alan Carvalho de Assis wrote: Hi Tomasz, Currently NuttX doesn't support 6502 and even the support to 8051 was removed some years ago. BTW, I think it could be possible to support C99 for 6502 if you use gcc: https://github.com/itszor/gcc-6502-bits BR, Alan On 1/8/22, Tomasz CEDRO wrote: On Sat, Jan 8, 2022 at 1:53 PM Gregory Nutt wrote: z80 holds all 8-bit ZiLOG architectures. That means z80 using the SDCC compiler z180 using the SDCC compiler ez80 which normally uses the ZiLOG compiler, but there is an experimental version of GCC for the ez80 z16 uses only ZiLOG compiler Also consider SH1 This will also require changes to INVIOLABLES.md and the coding standard. I would also recommend a formal vote to assure that you are following the will of the user base and not a personal agenda. There used to be a small but important group of retro computer folk using NuttX; this eliminates support for them. There is language in the INVIOLABLES that is there specifically to protect them from actions like this. I have not heard of anyone using these architectures recently. I would say that only ez80 is active with active development boards. There are occasional developments with z180-like hardware. One day I would love to run NuttX on 6502.. it would be nice if C99 wont make it impossible (why should it?).. but my knowledge is too small so I will look how the thread goes :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Move to C99 for common code
> > Speaking of the Z80, would it be possible to run NuttX in a Grant Searle > / RC2014 platform with a 8k ROM /56k RAM split, or would any attempt > require banked memory? > I don't know if it is possible or not. I don't know if NuttX is viable on any CPU limited to a 64Kb address space. In their day, those 8-bit CPUs were programmed in highly tuned assembly language. it is hard to imagine running an OS that is almost as big as the addressable memory and being able to do anything meaningful. NuttX may have outgrown these platforms. I think that z80 architecture support is still important because there are so many derivatives from z80, like that FPGA in the ZX Spectrum Next ( https://en.wikipedia.org/wiki/ZX_Spectrum_Next). That FPGA runs the z80 with a extended address space using an MMU similar to the z180 but with smaller pages. Other derivatives like the z300 and the ez80 just support a wider address space. I have done a couple of ezo ports recently (like http://z20x.computer/). I appreciate this discussion about protecting the NuttX supported platforms. > > So many RTOS are just for arm. > Originally, NuttX was focused on the hobbyist, DIYer, and retro-computing enthusiast. But nowadays, it is dominated by businesses with business value systems that are sometimes not compatible with the needs or interests of hobbyists. That is why there is such a long discussion in the INVIOLABLE.md under "All Users Matter." That was essentially the contract I made when I agreed to give the OS to the community. But it is going to take some strong leadership to keep those values since the OS is controlled completely by businesses now and businesses tend to think only of their own needs.
Re: Move to C99 for common code
On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt wrote: > > > > > Speaking of the Z80, would it be possible to run NuttX in a Grant Searle > > / RC2014 platform with a 8k ROM /56k RAM split, or would any attempt > > require banked memory? > > > > I don't know if it is possible or not. I don't know if NuttX is viable on > any CPU limited to a 64Kb address space. In their day, those 8-bit CPUs > were programmed in highly tuned assembly language. it is hard to imagine > running an OS that is almost as big as the addressable memory and being > able to do anything meaningful. NuttX may have outgrown these platforms. > > I think that z80 architecture support is still important because there are > so many derivatives from z80, like that FPGA in the ZX Spectrum Next ( > https://en.wikipedia.org/wiki/ZX_Spectrum_Next). That FPGA runs the z80 > with a extended address space using an MMU similar to the z180 but with > smaller pages. Other derivatives like the z300 and the ez80 just support a > wider address space. I have done a couple of ezo ports recently (like > http://z20x.computer/). > > I appreciate this discussion about protecting the NuttX supported platforms. I think non-arch-specific code should stick with C89 and we should not be too eager to remove architectures that have these needs. It's not too hard to tell people that non-arch-specific code needs to be C89. We can catch it more easily in precheck by passing the C89 flag to the compiler. Only in the case where an architecture is incomplete, unmaintained, and NuttX isn't really viable for it anymore, should we consider removing it. We should have a rule that removing an arch should require a process that makes it highly likely that we'd hear from any users who consider that arch important. For example, get the word out for some period of time and solicit feedback. If no feedback, then mark the arch deprecated, produce build-time warnings, require users to activate some kind of CONFIG_DEPRECATED_ARCH to use it. In other words, do things to get their attention. And then, have a mandatory waiting period to allow enough time to either attract maintainers or be able to declare the arch dead with a clear conscience. > > So many RTOS are just for arm. The whole point why I adopted NuttX is because of being able to move my applications from one arch to another. > Originally, NuttX was focused on the hobbyist, DIYer, and retro-computing > enthusiast. But nowadays, it is dominated by businesses with business value > systems that are sometimes not compatible with the needs or interests of > hobbyists. That is why there is such a long discussion in the > INVIOLABLE.md under "All Users Matter." That was essentially the contract > I made when I agreed to give the OS to the community. But it is going to > take some strong leadership to keep those values since the OS is controlled > completely by businesses now and businesses tend to think only of their own > needs. We need more hobbyist/DIYer committers and PMC. We need a short and professional presentation, targeted specifically to business users, that clearly explains why it is in their best interests to play nice with the community. Cheers, Nathan
Re: Move to C99 for common code
Following the discussion related to the "inline" keyword usage in common code. I have done draft changes in https://github.com/apache/incubator-nuttx/pull/5201 with an approach that possibly can be used to get rid of "inline" in common code. But I'm not even sure if this is needed to anyone, since there are no reports about compilation issues for any of the supported platforms. This means that the platforms are either not used (projects not updated to the latest NuttX release) or all used compilers support "inline" (and maybe C99). I would appreciate it if people can give feedback should I continue changing 7000 other places, or just drop this activity. Best regards, Petro пн, 10 січ. 2022 р. о 17:17 Nathan Hartman пише: > On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt wrote: > > > > > > > > Speaking of the Z80, would it be possible to run NuttX in a Grant > Searle > > > / RC2014 platform with a 8k ROM /56k RAM split, or would any attempt > > > require banked memory? > > > > > > > I don't know if it is possible or not. I don't know if NuttX is viable > on > > any CPU limited to a 64Kb address space. In their day, those 8-bit CPUs > > were programmed in highly tuned assembly language. it is hard to imagine > > running an OS that is almost as big as the addressable memory and being > > able to do anything meaningful. NuttX may have outgrown these platforms. > > > > I think that z80 architecture support is still important because there > are > > so many derivatives from z80, like that FPGA in the ZX Spectrum Next ( > > https://en.wikipedia.org/wiki/ZX_Spectrum_Next). That FPGA runs the z80 > > with a extended address space using an MMU similar to the z180 but with > > smaller pages. Other derivatives like the z300 and the ez80 just > support a > > wider address space. I have done a couple of ezo ports recently (like > > http://z20x.computer/). > > > > I appreciate this discussion about protecting the NuttX supported > platforms. > > I think non-arch-specific code should stick with C89 and we should not > be too eager to remove architectures that have these needs. > > It's not too hard to tell people that non-arch-specific code needs to be > C89. > > We can catch it more easily in precheck by passing the C89 flag to the > compiler. > > Only in the case where an architecture is incomplete, unmaintained, > and NuttX isn't really viable for it anymore, should we consider > removing it. > > We should have a rule that removing an arch should require a process > that makes it highly likely that we'd hear from any users who consider > that arch important. > > For example, get the word out for some period of time and solicit > feedback. If no feedback, then mark the arch deprecated, produce > build-time warnings, require users to activate some kind of > CONFIG_DEPRECATED_ARCH to use it. In other words, do things to get > their attention. And then, have a mandatory waiting period to allow > enough time to either attract maintainers or be able to declare the > arch dead with a clear conscience. > > > > So many RTOS are just for arm. > > The whole point why I adopted NuttX is because of being able to move > my applications from one arch to another. > > > Originally, NuttX was focused on the hobbyist, DIYer, and retro-computing > > enthusiast. But nowadays, it is dominated by businesses with business > value > > systems that are sometimes not compatible with the needs or interests of > > hobbyists. That is why there is such a long discussion in the > > INVIOLABLE.md under "All Users Matter." That was essentially the > contract > > I made when I agreed to give the OS to the community. But it is going to > > take some strong leadership to keep those values since the OS is > controlled > > completely by businesses now and businesses tend to think only of their > own > > needs. > > We need more hobbyist/DIYer committers and PMC. > > We need a short and professional presentation, targeted specifically > to business users, that clearly explains why it is in their best > interests to play nice with the community. > > Cheers, > Nathan >
Re: Move to C99 for common code
Even no people complain about the inline usage, but it's always good to isolate the inline keyword in compiler.h like others. On Tue, Jan 11, 2022 at 4:37 AM Petro Karashchenko < petro.karashche...@gmail.com> wrote: > Following the discussion related to the "inline" keyword usage in common > code. I have done draft changes in > https://github.com/apache/incubator-nuttx/pull/5201 with an approach that > possibly can be used to get rid of "inline" in common code. > But I'm not even sure if this is needed to anyone, since there are no > reports about compilation issues for any of the supported platforms. This > means that the platforms are either not used (projects not updated to the > latest NuttX release) or all used compilers support "inline" (and maybe > C99). > I would appreciate it if people can give feedback should I continue > changing 7000 other places, or just drop this activity. > > Best regards, > Petro > > пн, 10 січ. 2022 р. о 17:17 Nathan Hartman > пише: > > > On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt > wrote: > > > > > > > > > > > Speaking of the Z80, would it be possible to run NuttX in a Grant > > Searle > > > > / RC2014 platform with a 8k ROM /56k RAM split, or would any attempt > > > > require banked memory? > > > > > > > > > > I don't know if it is possible or not. I don't know if NuttX is viable > > on > > > any CPU limited to a 64Kb address space. In their day, those 8-bit > CPUs > > > were programmed in highly tuned assembly language. it is hard to > imagine > > > running an OS that is almost as big as the addressable memory and being > > > able to do anything meaningful. NuttX may have outgrown these > platforms. > > > > > > I think that z80 architecture support is still important because there > > are > > > so many derivatives from z80, like that FPGA in the ZX Spectrum Next ( > > > https://en.wikipedia.org/wiki/ZX_Spectrum_Next). That FPGA runs the > z80 > > > with a extended address space using an MMU similar to the z180 but with > > > smaller pages. Other derivatives like the z300 and the ez80 just > > support a > > > wider address space. I have done a couple of ezo ports recently (like > > > http://z20x.computer/). > > > > > > I appreciate this discussion about protecting the NuttX supported > > platforms. > > > > I think non-arch-specific code should stick with C89 and we should not > > be too eager to remove architectures that have these needs. > > > > It's not too hard to tell people that non-arch-specific code needs to be > > C89. > > > > We can catch it more easily in precheck by passing the C89 flag to the > > compiler. > > > > Only in the case where an architecture is incomplete, unmaintained, > > and NuttX isn't really viable for it anymore, should we consider > > removing it. > > > > We should have a rule that removing an arch should require a process > > that makes it highly likely that we'd hear from any users who consider > > that arch important. > > > > For example, get the word out for some period of time and solicit > > feedback. If no feedback, then mark the arch deprecated, produce > > build-time warnings, require users to activate some kind of > > CONFIG_DEPRECATED_ARCH to use it. In other words, do things to get > > their attention. And then, have a mandatory waiting period to allow > > enough time to either attract maintainers or be able to declare the > > arch dead with a clear conscience. > > > > > > So many RTOS are just for arm. > > > > The whole point why I adopted NuttX is because of being able to move > > my applications from one arch to another. > > > > > Originally, NuttX was focused on the hobbyist, DIYer, and > retro-computing > > > enthusiast. But nowadays, it is dominated by businesses with business > > value > > > systems that are sometimes not compatible with the needs or interests > of > > > hobbyists. That is why there is such a long discussion in the > > > INVIOLABLE.md under "All Users Matter." That was essentially the > > contract > > > I made when I agreed to give the OS to the community. But it is going > to > > > take some strong leadership to keep those values since the OS is > > controlled > > > completely by businesses now and businesses tend to think only of their > > own > > > needs. > > > > We need more hobbyist/DIYer committers and PMC. > > > > We need a short and professional presentation, targeted specifically > > to business users, that clearly explains why it is in their best > > interests to play nice with the community. > > > > Cheers, > > Nathan > > >
Support for Pimonori Tiny2040
Hi, I owned a Pimoroni Tiny2040 device. It’s an RP2040 based device with some interesting features: + small form factor (18x21.3mm) + 8 MByte Flash + RGB LED + Reset Button + USB-C - reduced pin-header I’d like to add the device based on the available RP2040 support. It’s basically working, but the specifics are missing. My plan is to re-use the code from 'boards/arm/rp2040/raspberrypi-pico‘ and and add the support in 'boards/arm/rp2040/pimoroni-tiny2040‘. Anything wrong with this approach? Regards Piet
