Create release and publish on crates.io

[no111u3]

I think library now ready to create release of some HAL's and ready to publish on crates.io.

[OliverEvans96]

Agreed, that would be great!

[Rahix]

This is, of course, the ultimate goal but for now I don't think we're there yet. There are quite a few architectural questions still to be solved which I want to have addressed before we flood crates.io with releases and crates ... Though maybe I should create a milestone to track the progress!

[stappersg]

(breaking silence after more then a year)

What is, beside available time, blocking this issue?

[tippfehlr]

(breaking silence after another year)

I'd love to see this on crates.io

[Beanow]

Wondered the same. Looking at

• https://github.com/Rahix/avr-hal/issues/130

There's a fair bit answered now in terms of refactoring into different crates. Other question probably being versioning:

• https://github.com/Rahix/avr-hal/issues/76

Indeed non-trivial but seems no conclusion yet. At least there.

[kpcyrd]

I'm also interested in this, after exploring the ESP32-C3 and RP2040-Zero I spent the last few weeks programming a Digispark ATTiny85 with avr-hal (after I ordered 25 of them). Since I'm using micronucleus for flashing I've created elf2nucleus for proper integration with cargo run.

I've also setup a "Hello world" example repository with everything configured for development with the Digispark ATTiny85 and micronucleus, documentation and github actions examples.

My main.rs currently looks like this:

#![no_std]
#![no_main]

use attiny_hal::{clock, delay::Delay, Peripherals, Pins};
use embedded_hal::blocking::delay::DelayMs;
use panic_halt as _;

#[no_mangle]
fn main() -> ! {
    let pac = Peripherals::take().unwrap();
    let pins = Pins::new(pac.PORTB);

    let mut delay = Delay::<clock::MHz8>::new();

    // Digital pin 1 is also connected to an onboard LED marked "L"
    let mut led = pins.pb1.into_output();
    led.set_high();

    loop {
        led.set_high();
        delay.delay_ms(500_u16);
        led.set_low();
        delay.delay_ms(1000_u16);

        led.set_high();
        delay.delay_ms(250_u16);
        led.set_low();
        delay.delay_ms(100_u16);
        led.set_high();
        delay.delay_ms(250_u16);
        led.set_low();
        delay.delay_ms(1000_u16);
    }
}

I used arduino_hal::pins! first but moved away from this approach because it made it harder to follow along with cargo doc output (some compile-time generated code vs simply looking at target/avr-attiny85/doc/attiny_hal/port/struct.Pins.html).

Having to write delay.delay_ms(250_u16); is slightly unfortunate, the way delay_ms is written, rustc generates a very confusing error because there's a generic implementation for both u8 and u16 (although the u8 implementation is simply calling the u16 implementation). If I'd write delay.delay_ms(250) rustc would not be able to infer the type of 250, default to i32 and then complain about a missing i32 implementation (the resulting error could scare off people who aren't year-long Rust veterans, you need to be able to read the list of available implementations from the error message, then know how to force specific integer types and know about this being a thing in the first place).

From my point of view, to consider the Digispark ATTiny85 on par with the ESP32-C3 and RP2040-Zero (considering the hardware limitations), the only thing missing are crates.io releases. You don't need to release a 1.0.0 right away, and even if you released breaking updates weekly this would be considered acceptable use of crates.io.

Without having any 0.X.0 snapshots to work with however, it's near impossible to develop libraries that build on top of this hal, your crate would either depend on avr-hal (main) and inadvertently break due to the lack of versioning, or you depend on a specific commit. However due to the way git dependencies are resolved in Rust you'd then need to depend on the exact same avr-hal commit to use this crate. git+https://github.com/rahix/avr-hal#bfd6d7c3ec8215eb1598068ff8bf444dad8cb960 and git+https://github.com/rahix/avr-hal?rev=bfd6d7c3ec8215eb1598068ff8bf444dad8cb960#bfd6d7c3ec8215eb1598068ff8bf444dad8cb960 (or any other commit) are considered two different crates, the same way that foo and bar are considered to be different crates.