Add ATtiny84A support

[MichaelDarr]

Overview

These changes add the ATtiny84a chip with EEPROM support.

Status

These changes are blocked on attiny84a support in avr-device. Once that PR is merged, a new version is released, and the avr-hal packages rely on that new version, these changes will be ready for proper review.

Risks

I'm not very familiar with this library yet, and my confidence in the correctness of these changes is low. I've only tested these changes with an ATtiny84a - there may be unintentional side effects for other chips.

In one case, I had to include the config attribute #[cfg(not(feature = "attiny84a"))]. I assume there's a better option available, perhaps by implementing the prescaler_n functions for the Attiny84a. I am unsure how to do this - is there some documentation I'm missing?

Testing

Locally, I've modified the relevant Cargo.toml files to target the relevant avr-hal version. Then, I was able to successfully read from and write to the EEPROM with the avr_hal_generic and attiny_hal libraries. I've included a simplified example below, and the full code can be found here (this code in this repo is very messy - it's a proof of concept which will be fully rewritten).

use attiny_hal;
use avr_device::attiny84a;
use avr_hal_generic;

type Eeprom = avr_hal_generic::eeprom::Eeprom<attiny_hal::Attiny, attiny84a::EEPROM>;

#[avr_device::entry]
fn main() -> ! {
    let dp = attiny84a::Peripherals::take().unwrap();
    let mut eeprom = Eeprom::new(dp.EEPROM);

    let mut read_data = [0_u8; 16];
    if eeprom.read(0, &mut read_data).is_err() {
        panic!("failed to read eeprom")
    }

    let mut write_data = [0_u8; 16];
    if eeprom.write(0, &mut write_data).is_err() {
        panic!("failed to write to eeprom")
    }
}

[Rahix]

Thanks a lot for the contribution and sorry for only getting to it now. The code is already looking very good, for a few minor comments, check below.

[Rahix]

Instead of duplicating the values from attiny84, you can also reuse the block by extending the #[cfg] above like this:

-#[cfg(feature = "attiny84")]
+#[cfg(any(feature = "attiny84", feature = "attiny84a"))]
 avr_hal_generic::impl_port_traditional! {

[Rahix]

Same here, just augment the attiny84 block:

-#[cfg(feature = "attiny84")]
+#[cfg(any(feature = "attiny84", feature = "attiny84a"))]
 #[macro_export]
 macro_rules! pins {
     ($p:expr) => {

[Rahix]

So, this is a multi-level issue:

First of all, to not build the ADC module for this chip, it would be better to disable it at crate level. Here:

avr-hal/mcu/attiny-hal/src/lib.rs

Lines 65 to 69 in 21342dc

	// ATtiny2313 does not have ADC and will not compile with this module
	#[cfg(all(feature = "device-selected", not(feature = "attiny2313")))]
	pub mod adc;
	#[cfg(all(feature = "device-selected", not(feature = "attiny2313")))]
	pub use adc::Adc;

However, the chip does have an ADC so this code shouldn't fail to compile. The reason it does is probably that registers in avr-device are not correctly defined. I've already investigated this and opened Rahix/avr-device#151 to fix it.

So I think the best course of action is to wait for the change to land in avr-device and then things should just work without the #[cfg(not())] line.