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 configurable board options to ravedude #521

Closed
Creative0708 opened this issue Mar 16, 2024 · 3 comments · Fixed by #522
Closed

Add configurable board options to ravedude #521

Creative0708 opened this issue Mar 16, 2024 · 3 comments · Fixed by #522
Labels

Comments

@Creative0708
Copy link
Contributor

I'm using Rust to program an ATtiny85 through an Arduino Nano, and I'd like to use ravedude as a convenient runner for this. This is easily doable with avrdude:

avrdude -p t85 -P /dev/<serial> -c avrisp -b 19200 -U flash:w:<file>

However, currently the board options are hardcoded in ravedude. I've resorted to modifying ravedude and adding a custom board option:

struct AvrIspAttiny85;

impl Board for AvrIspAttiny85 {
    // [...]

    fn avrdude_options(&self) -> avrdude::AvrdudeOptions {
        avrdude::AvrdudeOptions {
            programmer: "avrisp",
            partno: "t85",
            baudrate: Some(19200),
            do_chip_erase: true,
        }
    }

    // [...]
}

This isn't ideal. The proposal in #278 which uses TOML files to configure ravedude seems like the best option, and I'd be happy to work on implementing this into ravedude.
There are some considerations (at least, some that I've thought about) before work can be started/continued on this:

  • Whether we want this at all. This seems true, as making ravedude a generic tool for all AVR boards has been mentioned before (in the issue), but I wanted to confirm. After all, I don't want to write a PR that may not actually be merged
  • Whether the TOML format in the issue is finalized
  • Something about progress already made on this? Rahix mentioned starting work on something like this but not being able to finish it.

All things considered, this seems like a fun feature to implement and I'd like to work on this. If there are any issues that someone has with this plan, please leave feedback!

I could have made this a GitHub discussion, but since this is "technically" a feature request I figured it'd be better as an issue. If this would have been better as something else, let me know.

Thanks for making such an amazing tool!

@stappersg
Copy link
Contributor

stappersg commented Mar 16, 2024 via email

@Rahix Rahix added the ravedude label Mar 16, 2024
@Rahix
Copy link
Owner

Rahix commented Mar 16, 2024

This isn't ideal.

100% agree. It was a quick and dirty "get something shipped" approach but it is horrible in every regard.

The proposal in #278 which uses TOML files to configure ravedude seems like the best option, and I'd be happy to work on implementing this into ravedude.

Please got for it! As I mentioned, I wanted to add this myself but never found enough time to sit down and do it. So if you are interested in contributing this feature, I'd be very very grateful :)

Whether we want this at all.

Yes please!

Whether the TOML format in the issue is finalized

Not at all. It was just my first idea on what this could look like. Feel free to modify as you see fit.

Something about progress already made on this?

Nothing beyond the posted toml format idea.

I could have made this a GitHub discussion, but since this is "technically" a feature request I figured it'd be better as an issue. If this would have been better as something else, let me know.

Issue is the right place. We'll associate the issue with your PR once it exists.


I have a few more thoughts about this feature that I'd like to share. Open for discussion, of course.

  • I'd love to have proper error messages when the configuration file is incorrect or contains keys that ravedude doesn't know about. Like the errors and warnings cargo produces for Cargo.toml.
  • I think we should aim for project-specific configuration. So a Ravedude.toml next to Cargo.toml in the project directory where project-specific boards and settings are located.
  • The boards we define by default should not be customizable. So the "default config" should continue to be baked into ravedude. I want users to define a custom named board instead if they want to change some settings. For this, I think there should be some ravedude --dump-config uno argument to get the toml for a builtin board.

@Creative0708
Copy link
Contributor Author

Sounds good! I'll get working on a prototype. No complaints about your suggestions so far.

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

Successfully merging a pull request may close this issue.

3 participants