error: no matching package named `avr-hal` found

[mfp20]

There's no crate named avr-hal, why?

I apologize for being naive but this is my very first Rust project and ... I'm kind of dazed. I am developing an embedded firmware that should be able to run on AVR, stm32 and RP2040. With stm32 and rp2040 I can just use their HALs crates, but there's no equivalent crate for AVR. It seems like ravedude is the only dependency to be included but then I don't know what I have to "use" in code. It seems like I've started to dig into this setup when avr-hal is in some kind of migration (ex: to embedded-hal 1.0?). The examples in this repo use local paths: do I have to git clone this repo in my codebase? Documentation popping out from google is kind of obsolete or confusing. And I ended up messing up my rust installation.

Any help would be greatly appreaciated.

Thanks

[AlternativleyCoolSlimbo]

To reference the crate in a project, you must use the git(hub) repo link. In that case, adding the following line to your Cargo.toml under [dependencies]: avr-hal = { git = "https://github.com/Rahix/avr-hal", features = ["<insert respective board here>"] }. If you're after specific Arduino like behaviours for it, you can also specifically use "arduino-hal" (rename avr-hal to arduino-hal) (The only difference is pin mappings are mapped to the board names)

[mfp20]

To reference the crate in a project, you must use the git(hub) repo link.

That worked. Then I had to use the json file from avr-specs, and use the nightly toolchain. Well, it seems to work... it builds. Thanks.

At this point I've to figure out how to make cargo build the 3 different archs using 3 different toolchains; in docs they say the .cargo/config.toml files are ignored if the build process is tarted from the workspace's root directory. But this is not related to avr-hal.

[CoolSlimbo]

(Switched to my main account now, still me. however)

My recommendation is you create an abstraction over embedded_hal, using its traits, etc. Then you'll have to implement said abstraction for each architecture.

[mfp20]

My recommendation is you create an abstraction over embedded_hal, using its traits, etc. Then you'll have to implement said abstraction for each architecture.

ehm... the Hardware Abstraction Layer (HAL) is already there for any and all of the three archs. Here we are commenting the use of AVR one. In theory I should already have a common interface to any and all of the three MCUs thanks to embedded-hal traits and the work in avr-hal, and the other 2 HALs, using the embedded-hal traits. As an example I can see that all of the 3 HALs have hal:Peripherals and hal::pins. I can pass those 2 to my own structured code (ex: a scheduler) and it should be able to work on all of the three MCUs.

What abstraction are you writing about?

[CoolSlimbo]

I’m writing about exactly what you’ve said you’ve done.

That is, writing a common interface based on embedded-hal, and then implementing it for each arch.

[mfp20]

I’m writing about exactly what you’ve said you’ve done.

That is, writing a common interface based on embedded-hal, and then implementing it for each arch.

I haven't done it! avr-hal, rp2040-hal and the stm32-hal(s) are already there! There's no need to make another one!

[AlternativleyCoolSlimbo]

I have not said to make another one. That isn't how it would work. I'm saying, to achieve your goal, you'd need to create structs that use the trait objects provided by embedded-hal, which give you the common interface.

The abstraction I speak of is saying a struct that takes arguments of traits (of which are provided by e-h), and then, for each device it can be compiled for, construct the struct using the implementations from each hal.

I.e. create a "driver" (your fw), and then use the implementations for each kind of device you wish to support.