Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add examples #8

Open
6 tasks
2bndy5 opened this issue Jan 1, 2025 · 0 comments
Open
6 tasks

Add examples #8

2bndy5 opened this issue Jan 1, 2025 · 0 comments

Comments

@2bndy5
Copy link
Member

2bndy5 commented Jan 1, 2025

Here's the chips I'm looking to support in the rust examples:

  • The implementation of embedded-hal on Linux for SoM (System on Module) boards is freakishly easy to use.
  • The implementation of embedded-hal on RP2040 is designed to be run as bare metal (no RTOS).
  • The implementation of embedded-hal on ATSAMD seems to have abstractions for various related boards (which seem to be recommended in docs).
  • The implementation of embedded-hal on AVR (supports ATmega238 and ATTiny chips) is not even published to crates.io. This is odd and a bit of a red flag for me. I could pin to a git source using a commit SHA or tag, but the process of uploading the compiled binaries recommends using a tool that wraps around the AVRdude tool used by the Arduino IDE (see ravedude).
  • The implementation for embedded-hal on Nordic chips has several abstractions based (probably generated from) on the dev kit for each supported chip (ie nRF52840-hal). It is designed to be used on bare metal (no RTOS) and does not employ a softdevice (which is supported in the embassy project -- see below).
  • The implementation for embedded-hal on esp32 seems to be a rust binding to the ESP-IDF (written in C). Like the ESP-IDF, the embedded-hal for esp32 uses a custom tool to build and upload binaries to the board.

Writing the examples is tough. The embedded-hal implementations for various chips are not conformed like the Arduino Cores for various chips families. Writing an example for the RP2040 will look significantly different from an example for the ATSAMD21.

Due to this complexity, I've decided to try and put the examples in its own "crate" (a rust term for a library) in a sub-directory named "examples". This way I can allow users to control which chip to compile for using [cargo features][cargo-feat] defined in examples/cargo.toml.

Furthermore, flashing the compiled binary to a board requires a separate dependency called probe.rs. This is another reason why the examples need to use a separate crate.

Embassy Project

There is an embassy project that focuses on some SoC (System on Chip) that employ an RTOS. This seems useful for multi-processing, but it is ultimately unnecessary for simple examples. Nonetheless, I could use this embassy project for ESP32, RP2040, and nRF5x chips because they seem to have a somewhat unified API for those chips (I think).

Originally posted by @2bndy5 in #1 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant