Re: how to add unique_id for Raspberry Pi Pico?
Hello Alan and thanks for the warm welcome. Yes, the id is in the flash part of the board and the code for extracting the unique id is in the Pico bootrom. But how to acces and run bootrom code from a Nuttx application? The code for other boards seem to access an id in a processor register. And while access to flash fs on the Pico supposedly could give some hints, a solution still eludes me. Anders Originalmeddelande Den 25 feb. 2024 20:17, Alan C. Assis skrev: > Hi Anders, Welcome to NuttX !!! Yes, you are right, the rp2040 port doesn't > yet have support for uniqueid. If you want to add it, please enter inside > nuttx/arch/arm/src/ and "git grep uniqueid" for a reference how it is done in > other chips. Example in cxd56xx arch: arch/arm/src/cxd56xx/cxd56_uid.c And > cxd56xx common boards: boards/arm/cxd56xx/common/src/cxd56_uid.c Notice that > rp2040 doesn't have unique id like other chips, but you have use the flash > serial number as unique id, more info: > https://forums.raspberrypi.com/viewtopic.php?t=331910 BR, Alan On Sun, Feb > 25, 2024 at 9:58 AM Anders wrote: > Having just started to play with nuttx > running on Raspberry Pi Pico, I > discovered that configuring support for the > unique id functions results in > a build of nuttx that fails. My > understanding is that support for this is > not currently added. One can find > code for this for other boards in the > corresponding directory tree of > nuttx. > > Reading in the archives of this list, it is not recommended to use > > functions from the Pico-sdk. So new driver code should be added. > > What > is the recommended way of adding this functionality? Adding the > interface > in a separate file of boards/arm/rp2040/raspberry-pi-pico/src/ > and > Make.defs seems easy. But where would the code for actually interfacing > > with the flash best go? > > Anders
Re: Rust in the OS?
-1 from me for Rust in the kernel, +1 for Rust in apps. Sebastien and Tomek gave enough arguments to avoid Rust in the kernel. Not a technical argument from me: Rust has too many arrogant members in the community with a messianic approach (like `Rust will save embedded, blah, blah, blah`), it's quite irritating and bad for your mental health :) czw., 14 mar 2024 o 00:36 Tomek CEDRO napisał(a): > On Wed, Mar 13, 2024 at 10:03 PM Gregory Nutt wrote: > > On 3/13/2024 2:42 PM, Tomek CEDRO wrote: > > > You want Rust in the core go ahead write RustOS have fun maintaining > it for 5 years and show us its better :-) > > > > You are probably right in that. It would probably be necessary have to > > be a different OS if any extensive amount of Rust is used. POSIX > > defines a C interface to the OS with C function prototypes and C data > > types. I haven't looked at this carefully, but a significant use of > > Rust might jeopardize POSIX compatibility (or require a mess of C > > conversion wrappers). It would probably be better to have a pure RustOS > > with a non-POSIX, but POSIX-like OS interface. > > > > I am not a language chauvinist, but I think we should avoid the > > complexity and maintenance issues of a mixed language solution (as > > enumerated by others in this thread). > > I can see Lup is already on the GH thread this is good news :-) I > would suggest to limit Rust for the Application part and see how it > works.. just as we have Basic, Python, Lua, Zig, etc working on top of > existing untouched POSIX RTOS architecture.. then create several demos > using display sound etc to show others how to port Rust applications > to NuttX :-) > > > Below are my concerns in depth for our internal discussion.. maybe you > have similar thoughts.. and you can safely ignore that part :-) > > There are some Rust based OS already out there. Look how many! Some of > them does not even plan to support security mitigations, sensor > devices, BLE, WIFI, etc. Why? How does setup of those Rust OS SDK > compares to current NuttX environment setup and build times?? > > https://github.com/flosse/rust-os-comparison > > Instead of injecting unimaginable maintenance nightmare into existing > minimalistic projects Rust fans can simply focus on building new > alternative solutions and prove these are better in practice - by > results - they need to build commercial products on top of their OS, > ship it, maintain it, take full responsibility for the results, after > some years we will see how it works. I will be first to congratulate > and buy a good Open-Source based Rust product. But right now that push > for injecting Rust into all possible OS/RTOS seems really suspicious > not to say viral and dangerous!! > > Lup can do magic with NuttX like running applications written in other > programming languages and convert NuttX code to different programming > languages in order to run on new platforms and environments. All is > done in non-invasive way, respecting current architecture and backward > compatibility, adding new functionality that is optional and diamond > clean in maintenance. This is the only way to go! :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: Rust in the OS?
-1 from me for Rust in the kernel, +1 for Rust in apps Mixing languages in the kernel was never a good idea. Kernel should follow "as simple as possible" philosophy whenever it could. My opinion is that although Rust is safer than C, if you know what you are doing, a C is good enough. If you don't know what you are doing, Rust is dangerous too. On Wed, Mar 13, 2024 at 7:29 PM Gregory Nutt wrote: > There is some discussion in Issue #11907 proposing to use the Rust > language within the OS (vs Rust applications on a pure C OS). If anyone > has any feelings, Pro or Con, you should participate in this > discussion. This kind of decision impacts the entire community and > should have the input of all of the community that has an opinion. > > >
Re: Rust in the OS?
-1 from me for Rust in the kernel, +1 for Rust in apps. Pierre-Noël Bouteville Envoyé de mon iPhone > Le 14 mars 2024 à 09:51, raiden00pl a écrit : > > -1 from me for Rust in the kernel, +1 for Rust in apps.
Re: how to add unique_id for Raspberry Pi Pico?
Hi Anders, As I said the RP2040 doesn't have a unique id like others MCUs, then the solution they found was read from its SPI Flash, more info: https://github.com/raspberrypi/pico-sdk/pull/12 You need to look how they did it and use it in NuttX. BR, Alan On Thu, Mar 14, 2024 at 4:09 AM Anders wrote: > Hello Alan and thanks for the warm welcome. > > Yes, the id is in the flash part of the board and the code for extracting > the unique id is in the Pico bootrom. But how to acces and run bootrom code > from a Nuttx application? > The code for other boards seem to access an id in a processor register. > And while access to flash fs on the Pico supposedly could give some hints, > a solution still eludes me. > > Anders > > Originalmeddelande > Den 25 feb. 2024 20:17, Alan C. Assis skrev: > > > Hi Anders, Welcome to NuttX !!! Yes, you are right, the rp2040 port > doesn't yet have support for uniqueid. If you want to add it, please enter > inside nuttx/arch/arm/src/ and "git grep uniqueid" for a reference how it > is done in other chips. Example in cxd56xx arch: > arch/arm/src/cxd56xx/cxd56_uid.c And cxd56xx common boards: > boards/arm/cxd56xx/common/src/cxd56_uid.c Notice that rp2040 doesn't have > unique id like other chips, but you have use the flash serial number as > unique id, more info: > https://forums.raspberrypi.com/viewtopic.php?t=331910 BR, Alan On Sun, > Feb 25, 2024 at 9:58 AM Anders wrote: > Having just started to play with > nuttx running on Raspberry Pi Pico, I > discovered that configuring support > for the unique id functions results in > a build of nuttx that fails. My > understanding is that support for this is > not currently added. One can > find code for this for other boards in the > corresponding directory tree > of nuttx. > > Reading in the archives of this list, it is not recommended > to use > functions from the Pico-sdk. So new driver code should be added. > > > What is the recommended way of adding this functionality? Adding the > > interface in a separate file of boards/arm/rp2040/raspberry-pi-pico/src/ > > and Make.defs seems easy. But where would the code for actually interfacing > > with the flash best go? > > Anders
Re: Rust in the OS?
I think there is a reference project that we can use as base: https://github.com/tylerwhall/zephyr-rust It doesn't seem to implement the drivers or anything else in the kernel. Best Regards, Alan On Wed, Mar 13, 2024 at 8:36 PM Tomek CEDRO wrote: > On Wed, Mar 13, 2024 at 10:03 PM Gregory Nutt wrote: > > On 3/13/2024 2:42 PM, Tomek CEDRO wrote: > > > You want Rust in the core go ahead write RustOS have fun maintaining > it for 5 years and show us its better :-) > > > > You are probably right in that. It would probably be necessary have to > > be a different OS if any extensive amount of Rust is used. POSIX > > defines a C interface to the OS with C function prototypes and C data > > types. I haven't looked at this carefully, but a significant use of > > Rust might jeopardize POSIX compatibility (or require a mess of C > > conversion wrappers). It would probably be better to have a pure RustOS > > with a non-POSIX, but POSIX-like OS interface. > > > > I am not a language chauvinist, but I think we should avoid the > > complexity and maintenance issues of a mixed language solution (as > > enumerated by others in this thread). > > I can see Lup is already on the GH thread this is good news :-) I > would suggest to limit Rust for the Application part and see how it > works.. just as we have Basic, Python, Lua, Zig, etc working on top of > existing untouched POSIX RTOS architecture.. then create several demos > using display sound etc to show others how to port Rust applications > to NuttX :-) > > > Below are my concerns in depth for our internal discussion.. maybe you > have similar thoughts.. and you can safely ignore that part :-) > > There are some Rust based OS already out there. Look how many! Some of > them does not even plan to support security mitigations, sensor > devices, BLE, WIFI, etc. Why? How does setup of those Rust OS SDK > compares to current NuttX environment setup and build times?? > > https://github.com/flosse/rust-os-comparison > > Instead of injecting unimaginable maintenance nightmare into existing > minimalistic projects Rust fans can simply focus on building new > alternative solutions and prove these are better in practice - by > results - they need to build commercial products on top of their OS, > ship it, maintain it, take full responsibility for the results, after > some years we will see how it works. I will be first to congratulate > and buy a good Open-Source based Rust product. But right now that push > for injecting Rust into all possible OS/RTOS seems really suspicious > not to say viral and dangerous!! > > Lup can do magic with NuttX like running applications written in other > programming languages and convert NuttX code to different programming > languages in order to run on new platforms and environments. All is > done in non-invasive way, respecting current architecture and backward > compatibility, adding new functionality that is optional and diamond > clean in maintenance. This is the only way to go! :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
