Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    enaut
    @enaut:matrix.org
    [m]
    as that is my only proof of concept project so far no need to upgrade ;)
    rahix
    @rahix:matrix.org
    [m]
    alright, try generating a project with cargo generate --git https://github.com/Rahix/avr-hal-template.git --branch wip and then selecting Nano168 as the board. If I didn't mess anything up, cargo run should be enough with that to make your board blink (might need to set a port with cargo run -- -P /dev/ttyFOO).
    enaut
    @enaut:matrix.org
    [m]
    rahix Thank you so much! unfortunately I'm still not getting there... result now is:
    cargo run --bin test-nano168
        Finished dev [optimized + debuginfo] target(s) in 0.02s
         Running `ravedude nano168 -cb 57600 -P /dev/ttyUSB0 target/avr-atmega168/debug/test-nano168.elf`
           Board Nano Clone (ATmega168)
     Programming target/avr-atmega168/debug/test-nano168.elf => /dev/ttyUSB0
    and then nothing happens
    the weired thing is my other project works now with only cargo run (after I pasted the code from your example)
    rahix
    @rahix:matrix.org
    [m]
    huh, that is super strange
    enaut
    @enaut:matrix.org
    [m]
    Oh I found the difference what does profile=minimal in toolchain.toml do?
    on removing that everything works as expected
    rahix
    @rahix:matrix.org
    [m]
    oh really? that is confusing
    it shouldn't have an influence whatsoever... here is relevant documentation: https://rust-lang.github.io/rustup/concepts/profiles.html
    it just controls whether rustfmt and clippy are installed for the toolchain
    enaut
    @enaut:matrix.org
    [m]
    that is indeed confusing...
    rahix
    @rahix:matrix.org
    [m]
    especially because it should have influenced the other project exactly the same...
    enaut
    @enaut:matrix.org
    [m]
    dammit I'm dumb...
    I searched for the difference... and the only issue was... I was still connected to the Serial port in the other window...
    So the template works just fine!
    rahix
    @rahix:matrix.org
    [m]
    ooh, yeah that makes a lot of sense :)
    alright, then I'll go ahead and get all those changes merged now
    enaut
    @enaut:matrix.org
    [m]
    And thank you so much for solving my problem immediately!
    rahix
    @rahix:matrix.org
    [m]
    heh, no problem :) if you need anything else let me know!
    enaut
    @enaut:matrix.org
    [m]
    I will get better and bother you with harder problems 😛
    rahix
    @rahix:matrix.org
    [m]
    haha, challenge accepted :p
    enaut
    @enaut:matrix.org
    [m]
    Rahix (Rahix) I have ported the blink and the adc example (the second without the temperature) see pr
    *ported to the atmega168
    rahix
    @rahix:matrix.org
    [m]
    nice, thanks! :)
    enaut
    @enaut:matrix.org
    [m]
    rahix - in the pr you requested to change the comment to Nano 168 - shouldn't that be consistent with the verbose naming in the feature doc: "Nano clone (ATmega168)"?
    or do you prefer the more readable variant?
    rahix
    @rahix:matrix.org
    [m]
    honestly it does not matter much at all - I just was a bit weary about reading "Arduino" in code related to a board which is not an official one
    so choose whatever you think is best, it's not important ;)
    enaut
    @enaut:matrix.org
    [m]
    either me or my git allways gets confused... sometimes both... :) I work too much alone...
    but now it should be as desired in the pr (force pushed)
    enaut
    @enaut:matrix.org
    [m]
    what are good settings for rust-analyzer? Currently it is allways failing with the macros like ufmt::uwriteln! so whenever I open a project or file depending on avr-hal it is complaining about so many problems.
    rahix
    @rahix:matrix.org
    [m]
    I just disabled the lint complaining about those macros
    enaut
    @enaut:matrix.org
    [m]
    ok
    quentin
    @quentinmit:matrix.org
    [m]
    I'm trying to add attiny support to arduino-hal and I was wondering if there's anyone who could help with some of the trickier generics/trait bounds
    rahix
    @rahix:matrix.org
    [m]
    👋
    Although I am not quite sure, what you want to do? attinies by themselves belong into attiny-hal
    quentin
    @quentinmit:matrix.org
    [m]
    rahix: The main thing is that avr-hal-generic makes a bunch of mega-specific assumptions
    So I need to figure out how to move the mega-specific stuff into atmega-hal and make avr-hal-generic generic to allow a corresponding implementation in attiny-hal
    rahix
    @rahix:matrix.org
    [m]
    what in particular? the only mega-specific things should be contained in the impl_* macros
    so for tiny, the idea would be to write a second impl_* macro in avr-hal-generic which can then be used in attiny-hal
    quentin
    @quentinmit:matrix.org
    [m]
    (e.g. I filed Rahix/avr-hal#201 with slightly more specifics for the usart types.)
    rahix
    @rahix:matrix.org
    [m]
    hmm, I see
    quentin
    @quentinmit:matrix.org
    [m]
    Likewise the adc module has ReferenceVoltage baked into avr-hal-generic, though I think I've already successfully teased that apart.
    rahix
    @rahix:matrix.org
    [m]
    well Baudrate should stay a type valid for all supported MCUs, not a HAL specific one, IMO. But I agree that we need to maybe move the calculation logic into the mega-specific impl_ macro instead, to accommodate for attinies
    quentin
    @quentinmit:matrix.org
    [m]
    If it's a generic type then it shouldn't have ubrr and u2x fields.
    1 reply
    Shouldn't Baudrate be a trait, with HAL-specific implementations?
    Why does that require a concrete type?