lvanasse commented on PR #2487: URL: https://github.com/apache/nuttx-apps/pull/2487#issuecomment-2580528764
> Actually I'm not too clear if we should stick to the Official Rust Embedded HAL for NuttX. Here's why... > > To blink an LED in Rust Embedded HAL: We fetch the GPIO, then switch it off and on: https://docs.rust-embedded.org/discovery/microbit/05-led-roulette/light-it-up.html > > But there's no need to do this in NuttX! We simply open the LED Device `/dev/userleds`. And control it via ioctl: https://lupyuen.github.io/articles/rust6#blink-the-led > > Embedded HAL feels strange when we force-fit it into NuttX. I think I2C will have similar issues: https://lupyuen.github.io/articles/rusti2c#nuttx-embedded-hal > > If we look at Rust on Zephyr: They are proposing to use a Native Zephyr API to blink the LED [zephyrproject-rtos/zephyr#65837](https://github.com/zephyrproject-rtos/zephyr/issues/65837) > > ```rust > #![no_std] > #![no_main] > > #[zephyr::entry] > fn main() { > let dt = zephyr::devicetree::take().unwrap(); > let led = dt.chosen.led0; > loop { > led.toggle().unwrap(); > zephyr::sys::sleep(1000); > } > } > ``` > > My gut feel is that we should do it the Zephyr way. But make it POSIX-like. Thus we should drop `nuttx-embedded-hal` altogether :-) Thank you @lupyuen for the great research as always! What is your opinion on the idea of restarting the development of the NuttX API in the [rustix](https://github.com/bytecodealliance/rustix/tree/nuttx) crate? Would that make sense? And if not, we can always create our own nuttx-rs crate, maybe based on @no1wudi repo :)? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
