Skip to content

Add Attiny417/817/1617/3217 support #184

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

G33KatWork
Copy link

This patch adds support for the Attiny417, 817, 1617 and 3217.
These are all tinyAVR 1-series devices.

I added a lot of SVD patches for all tinyAVR devices in the common definition and one specific patch for the TCD timers that seem to be available only for the 1-series chips.

The patches add a lot of fixes and make things more ergonomically usable by properly turning things into arrays, adding proper enum values or fixing access (RW, RO, WO etc.) issues. They should all be fine, but might break other people's code. I am not sure what your policy is on something like this.

@Rahix
Copy link
Owner

Rahix commented Apr 16, 2025

Hi, thanks a lot for your contribution! Just a heads-up, I am holding off merging new chips right now until #157 is merged, which quite significantly changes the way the register definitions are generated. I will ping you once this change has landed so you can rebase your changes ontop of it.

@Rahix
Copy link
Owner

Rahix commented Apr 18, 2025

Here's the notification: #157 was merged 🎉 Please rebase your work ontop of the new code-generation. You should be able to make out the new structure in src/devices/mod.rs from the way things look for the existing chips. The Makefile is dropped completely.

@Rahix
Copy link
Owner

Rahix commented Apr 18, 2025

The patches add a lot of fixes and make things more ergonomically usable by properly turning things into arrays, adding proper enum values or fixing access (RW, RO, WO etc.) issues. They should all be fine, but might break other people's code. I am not sure what your policy is on something like this.

Simple: That's what semantic versioning is for. I'll bump the version appropriately to release such breaking changes. No need to hold back improvements, especially as we are still in 0 versioning land :D

In more serious terms: I am not afraid of releasing breaking changes for avr-device as users rarely need to update the version of this crate in their projects. On top of that, with #157, a lot has changed in the access API anyway (due to a much newer version of svd2rust), so users need to adapt in any case.

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

Successfully merging this pull request may close these issues.

2 participants