More cohesive integration with cargo

[innermatrix]

I would like to see more cohesive integration of AVR dev tools with cargo. Specifically, I would like to see the following:

• cargo avr flash: a command that flashes a binary to a board or a bare chip (similar to what ravedude is doing right now, but not quite the same; details below).
• cargo avr run: a command that flashes a binary and then opens a serial console to the target board / chip. Similar to ravedude with --open-console.
• cargo avr test: a command that can run tests on an attached board / chip (or in an emulator) and is interoperable with tools that work with cargo test today.

I am opening this as a tracking issue / a place for discussion of the big picture.

This idea is inspired by probe-rs and embedded-test, which provide similar functionality for Arm-based MCUs.

Here are the basic ideas that motivate me:

1. I think that having a wrapper around avrdude that can be used as a cargo runner is an excellent idea
2. I think that having a tool that can easily manage a serial console to an attached chip/board is an excellent idea
3. I think that putting both of those excellent ideas inside a tool named ravedude is unfriendly to newcomers, because it exposes an implementation detail (the name of the underlying avrdude dependency), and I think that we can do better to make our tooling clear
4. I think that we should lean into the rust tooling ecosystem and its existing affordances by making AVR tooling a custom cargo command
5. The actions that I commonly want to take today are "flash this binary to my hardware", "interact with my binary running on the hardware", and (not yet but hopefully soon) "run a test on my hardware (or in the emulator), like I would run any other test"

As a result, I propose that we add the commands I described above. In more detail, here's what I would like to see:

• cargo avr flash chip [mcu] [programmer] [port] [binary]
• cargo avr flash board [board] [binary]
• cargo avr run chip [mcu] [programmer] [port] [binary]
• cargo avr run board [board] [binary]
• cargo avr test chip [mcu] [programmer] [port] [binary]
• cargo avr test board [board] [binary]

With the following behaviors:

• All commands would take the binary as the last positional argument. This will make them usable as cargo runners (or cargo test runners)
• All commands would have a chip subcommand and a board subcommand.
• Each chip subcommand would require you to specify the specifics of which chip you are connecting to (which chip, which programmer, which port) — either as command line args or as environment variables. These would be used mainly for low-level work (like, for example, if you are testing support for a new MCU in hal-attiny, on a bare breadboard, without an entire board built around it).
• Each board subcommand would required you to specify the board that you are connecting to — either as a command line arg or as an environment variable — and would infer the chip and programmer from the board name and a board config file. These commands would be used for high-level work (for example, in board-specific examples, and by most end-users of avr-hal).
• All commands would allow you to specify the chip/board settings either in a manifest file or with command line / environment arguments.
• All commands should work correctly, and analogously to existing cargo tooling, with regards to multi-binary crates, crates with one or more examples, and crates with one or more tests.

With that, we would be able to do AVR-specific things that look similar to their plain cargo counterparts:

• Flash binaries in a multi-binary crate:

Use cargo avr flash board [board] or cargo avr run board [board] as runner, then

cargo run --bin binary_one
cargo run --bin binary_two

• Flash a binary to different boards with different chips:

Use cargo avr flash board [board] or cargo avr run board [board] as runner, then

cargo run --features [board-one] --bin binary_one
cargo run --features [board-one] --bin binary_two

• Have a MCU HAL crate whose examples can be run on different bare chips:

Use cargo avr flash chip [chip] [programmer] [port] or cargo avr run chip [chip] [programmer] [port] as runner, then

cargo run --features [chip-one] --example example_one
cargo run --features [chip-two] --example example_two

• Write unit tests and run them on hardware:

Use cargo avr test chip [chip] [programmer] [port] as test runner, then

cargo test --features [chip-one] --test test_one
cargo test --features [chip-two] --test test_two

The main ways in which this differs from what ravedude offers today are:

• Integration with cargo
• Clearer command naming
• Clear delineation between cargo avr flash and cargo avr run
• Access to the lower-level avrdude interface through the chip subcommands
• No requirement for a board manifest (thereby making it easier to target multiple boards / chips from one crate)

The main things that need to happen in code to accomplish this are:

• Pull existing parts of ravedude into a lib that cargo avr can be built on top of
• Start implementing the flash and run commands

Testing-related functionality would come later (because it requires working out a number of more complex issues, like how to set up a custom test harness and how to incorporate that into a cargo test-compatible interface.

To be clear, I am not proposing that we get rid of ravedude; I just want to pull its core pieces into a library and build a new CLI on top of that core, and thereby (I think) point us towards tooling that is clearer and that will scale better to support more use cases.

If you would like some code to go along with these conceptual thoughts, I have a preliminary implementation of cargo avr flash chip and cargo avr flash board in my fork @ innermatrix#5.