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

Create release and publish on crates.io #59

Open
no111u3 opened this issue Aug 20, 2020 · 6 comments
Open

Create release and publish on crates.io #59

no111u3 opened this issue Aug 20, 2020 · 6 comments
Assignees

Comments

@no111u3
Copy link
Contributor

no111u3 commented Aug 20, 2020

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

@OliverEvans96
Copy link

Agreed, that would be great!

@Rahix
Copy link
Owner

Rahix commented Sep 21, 2020

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!

@Rahix Rahix added this to the crates.io Release milestone Sep 21, 2020
@Rahix Rahix self-assigned this Oct 26, 2020
@stappersg
Copy link
Contributor

(breaking silence after more then a year)

What is, beside available time, blocking this issue?

@tippfehlr
Copy link
Contributor

tippfehlr commented Feb 27, 2023

(breaking silence after another year)

I'd love to see this on crates.io

@Beanow
Copy link

Beanow commented Oct 18, 2023

Wondered the same.
Looking at

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

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

@kpcyrd
Copy link

kpcyrd commented Jan 8, 2024

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.

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

No branches or pull requests

7 participants