During the build of this crate, the main bottleneck is the generation of the mcu description files. The compilation itself takes far less time. Therefore, optimizing the build will lead to faster builds.

Due to the bug in https://github.com/avr-rust/avr-mcu (CARGO_CFG_TARGET_CPU environment variable actually is not being set by avr-rust compiler), and also because cfg!(arch = "avr") doesn't work for unknown reason, build.rs always generates files for ALL microcontrollers, even if you specify one in custom target *.json file via "cpu": "atmega88pa" line, like in blink example.

So I decided to take a look at the code. Now avr-mcu uses TARGET environment variable to get the name of *.json file. It should be the same as -mmcu flag passed to avr-gcc. I understand that this change breaks blink example and other projects, so I bumped minor version number instead of patch.

PR for avr-mcu: https://github.com/avr-rust/avr-mcu/pull/9

Reverts avr-rust/avrd#16

avrd-tests.log

@Logarithmus it looks like this breaks the tests (I'm not sure why Travis didn't catch that), I have reverted and I can re-merge it once fixed.

This patch is only cosmetic. It silences these warnings:

warning: trait objects without an explicit `dyn` are deprecated
   --> build.rs:136:47
    |
136 |     pub fn mcu_module_code(mcu: &Mcu, w: &mut Write)
    |                                               ^^^^^ help: use `dyn`: `dyn Write`
    |
    = note: `#[warn(bare_trait_objects)]` on by default

This PR implements the parsing of value groups. Because the values in value groups represent a group, I have generated modules with constants.

I feel the code may be a little messy. Feedback would be appreciated.

This PR fixes issue #1.

The check for the target arch in the build script doesn't work.

https://github.com/avr-rust/avrd/blob/6072399dfe037d2807abb4058d4da6f045cc3f6c/build.rs#L13 Checking the environment variable CARGO_CFG_TARGET_ARCH would probably be the correct way (like avr_mcu::is_compiling_for_avr()).

I would have submitted a pull request, but with rustc 1.47.0-nightly (6c8927b0c 2020-07-26) I get the following error when retrieving the current mcu.

thread 'main' panicked at 'cannot retrieve mcu name, use a version of the avr-rust compiler that exposes the 'target_cpu' configuration option', avr-mcu-0.2.6\src\current.rs:35:24

I'm guessing, this will have to wait until a solution for exposing target_cpu is found.

It seems that documentation failed to build for 0.3.0: https://docs.rs/crate/avrd/0.3.0

If you look at the build log, there's a panic with message "Read-only filesystem". I think it's docs.rs problem. But why 0.2.0 built successfully? Is it a regression?

At the moment, all registers have their associated bitfields in the crate docs.

We should insert a link so it is clickable and takes the user to the bitfield constant.

I imagine that there are AVR devices which have IO ports where only half of the bits are actually connected to pins.

We might want to look into something like defining PB1, PB2, ... registers for each generated module. That way, if you're using the library and you try to use a pin that doesn't exist, it will hit a hard error.

It may make sense for us to convert the build script into a normal script and committing all generated cores to VCS.

This makes it quicker, and also means that we can very easily see the diff between changes in generated files.

It also means that diffs would be larger.