update to avr-device 0.7

[tones111]

I'm not sure why these weren't updated with the release of avr-device 0.6. Since everything depending on these HALs need to use the same avr-device version it seems like a good idea to keep them synced.

Is there a good method to test this type of change locally? Trying to run cargo check on the main branch results in a lot of errors.

[stappersg]

On Tue, Dec 31, 2024 at 01:29:25PM -0800, Paul Sbarra wrote: I'm not sure why these weren't updated with the release of `avr-device` 0.6. Since everything depending on these HALs need to use the same `avr-device` version it seems like a good idea to keep them synced. Is there a good method to test this type of change locally? Trying to run `cargo check` on the main branch results in a lot of errors.

Happy new year

[stappersg]

On Wed, Jan 01, 2025 at 04:28:15AM -0800, Geert Stappers wrote: Happy new year

In #623 did I a better attempt to express Welcome new contributor, please be aware that this project has currently growing pains. Groeten Geert Stappers -- Silence is hard to parse

[innermatrix]

@tones111 FWIW I use this to bulk-compile all examples during development:

find examples -name Cargo.toml -execdir cargo build --bins \;

(Yes, we should add that to CI.)

[Rahix]

@tones111, the reason I held off upgrading to avr-device 0.6 so far was the large amount of pending change in that project which push for yet another breaking release soon (== avr-device v0.7). So I intended to skip 0.6 for the time being. The 0.6 release also doesn't include much of value for avr-hal anyway.

[Rahix]

Is there a good method to test this type of change locally?

I usually just let CI take care of this, to be honest... That's the most dependable result one can get so I prefer it to attempting local builds. Otherwise, the suggestion from @innermatrix doesn't seem too bad.

(Yes, we should add that to CI.)

CI is already doing a matrix build of all the example crates and for MCUs without examples, it does a simple build-test of the HAL crate with the right features.

[innermatrix]

The 0.6 release also doesn't include much of value for avr-hal anyway.

@Rahix Well, it doesn't right now, but one of the reasons that I am adding ATtiny xmega support to avr-device is that I am also working on supporting those in avr-hal. Then again, that is gated on the conversation in #623 and my changes in #605 so I agree that there is no hurry to update avr-device until we make progress on those.

[tones111]

My motivation for this update was to allow downstream users of the HAL crates to use newer avr-device versions. Without it cargo ends up trying to link in both 0.5 and 0.6 which errors at link time due to duplicate symbols. I'll update this to depend on 0.7.

update: re-push once 0.7 has been published

[Rahix]

Thanks a lot!

[JoHaHu]

I would like to propose to instead change the dependency to ">=0.5". Then cargo can do it's dependency resolution magic and both 0.5 and 0.7 are supported for consumers of this library, until there are actually breaking changes where the minimum version needs to be bumped.

[Rahix]

Hm, this already doesn't work anymore because we merged #608 which makes 0.7 a hard requirement... In general, there are usually numerous PRs in avr-hal waiting for avr-device releases, so this is always going to be a problem.

Unfortunately we can't model feature to dependency version relationships so we have to upgrade the dep globally.

[innermatrix]

@Rahix One way out of this would be for each MCU and each board to get their own crate, which is a thing we could potentially consider after the refactors I proposed in #605 and #606. So potentially we can revisit this later, but yeah, right now I agree there's no way to get there from here.

[Rahix]

@innermatrix, this was actually what we and many others in the embedded-rust community did in the past. However it quickly became clear that the maintenance burden of "one hal per chip" was unmanageable. Additionally, crates.io and especially docs.rs were not happy about the large influx of mostly-generated small-size chip-description crates. That's how we ended up with the current "family crates with device features" situation.

Off-topic: I'll get back to all your other issues and PRs soon @innermatrix, sorry for the latency, it's quite a lot to work through 😅

[innermatrix]

@Rahix That makes sense, thanks for the context!

No rush on the other stuff, I get it.