Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ayke
    @aykevl:matrix.org
    [m]
    With some more tests, it appears that even recent GCC versions on other architectures also don't delete the null pointer, while LLVM does. I wonder why. Maybe the GCC developers never really cared about this particular optimization.
    Jesús Hernández
    @jhg
    @aykevl:matrix.org I totally agree, I made the clarification only coz with folks I realize about many confusions often because the influence of C
    Yes, I'll stick in the end to assembly as solution but I want to remove it from the crate where I need and move it to one separate crate only for it, to expose it as an rust enum
    jaxter184
    @jaxter184:matrix.org
    [m]
    whats the current plan on how to split the crates? i havent checked in in a long time, and last i heard, the crates were gonna be split into atmega/attiny/avrxmega, and the issues seem to point that way, but that was a long time ago
    i read an article today that changed my mind on how i think they should be split; it was about when to use rust feature flags and when to not. i feel like while it might be easier to maintain and update the crates when theyre combined like this, i think its better for usability to split them into separate crates as much as possible
    rahix
    @rahix:matrix.org
    [m]
    I do not see the benefit... For users it's just the difference between [dependencies.arduino-uno] version = "..." and [dependencies.arduino-hal] version = "..." features = ["arduino-uno"]. What does the former bring that the latter can't? The other way around, however, I see a lot: A unified crate means switching from one board to another is a single change in Cargo.toml; it allows writing "addon" crates that work with any of the arduino-hal supported boards without needing even more feature hell; it eases maintenance a lot because we do not duplicate the HAL for each supported device, but keep a single version for all. And because of that, we also don't run into the risk that individual HALs start to diverge - with a single source of truth, we can be certain that the API looks the same for everyone; no features which are only supported by one but not the others.
    jaxter184
    @jaxter184:matrix.org
    [m]

    For users it's just the difference between [dependencies.arduino-uno] version = "..." and [dependencies.arduino-hal] version = "..." features = ["arduino-uno"]. What does the former bring that the latter can't?

    im thinking about it less in terms of what each option is capable of and more about what is more intuitive to the user. imo, calling a chip or board a "feature" isnt really intuitive, but theres not a huge difference either way.

    ignoring the avr-hal-generic crate, which i think will be there regardless of which strategy is chosen, it feels to me like the amount of shared code is faily insignificant compared to the amount of unique code specific to a given crate. looking at the attiny crate in the next branch, it looks like the only code not covered under the chip feature flags is a few imports (though i may be reading it wrong).

    it allows writing "addon" crates that work with any of the arduino-hal supported boards without needing even more feature hell

    shouldnt any addon crates use embedded-hal rather than arduino-hal? i feel like it would be bad practice for an addon crate to depend on any arduino-specific features, though i can certainly see it being more convenient

    it eases maintenance a lot because we do not duplicate the HAL for each supported device, but keep a single version for all.

    i guess this is the most important difference. if separating the crates is significantly more difficult to maintain than combining them, then its probably not even worth thinking about splitting them unless some catastrophic issue comes up

    And because of that, we also don't run into the risk that individual HALs start to diverge

    why is it so bad if they start to diverge? sure, its better for them to all be the same, but if implementing a feature for some particular chip is somehow more difficult or time consuming than for other chips, wouldnt it be nice to be able to diverge them for more efficient releases? especially if the problematic chip is not commonly used

    ultimately, i havent done that much work for this crate, especially compared to you, but i just felt like i should correct my previous opinion since it has changed since i last expressed it. im sure regardless of which strategy you decide to take, itll still be just as good of a crate either way.

    rahix
    @rahix:matrix.org
    [m]

    im thinking about it less in terms of what each option is capable of and more about what is more intuitive to the user. imo, calling a chip or board a "feature" isnt really intuitive, but theres not a huge difference either way.

    true, and ultimately this is an abuse of cargo's feature system, for lack of a better option. Ideally, we'd get something like rust-lang/cargo#2980 to solve it properly.

    looking at the attiny crate in the next branch

    attiny-hal is a bad choice because it is so bare-bones. atmega-hal is much bigger already and you can see how multiple MCUs share certain items. With separate crates we'd have to duplicate all that.

    shouldnt any addon crates use embedded-hal rather than arduino-hal?

    It really depends. embedded-hal is for anything truly platform-agnostic, e.g. a plain sensor driver. Targeting arduino-hal makes sense for libraries which are specific to Arduino boards, but still work across the entire family. Think, for example, of a crate supporting a certain Arduino shield.

    why is it so bad if they start to diverge?

    it's hell when things work differently across different MCUs. The entire point of a HAL is to abstract away the details of each MCU so you get a common interface ontop. Also, you'll have to re-learn the API each time and always be cautious if you missed some non-obvious difference. By forcing a common API, we'll ensure this can never happen and that if an API is supported across multiple MCUs it is guaranteed to work the same. If one MCU is harder to support, we can still cfg() out the relevant stuff until it's implemented.

    On a different note, I recently created https://github.com/Rahix/avr-hal-template as an easier starting ground for new projects. It is already based on the next branch of avr-hal.
    rahix
    @rahix:matrix.org
    [m]
    enaut
    @enaut:matrix.org
    [m]
    hey all, I'm just starting with arduino etc. I wanted to use ravedude to flash the arduino. however I'm stuck with: avrdude: stk500_recv(): programmer is not responding avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
    rahix
    @rahix:matrix.org
    [m]
    hi enaut
    what board are you using?
    enaut
    @enaut:matrix.org
    [m]
    using avrdude it works with: avrdude -C/etc/avrdude/avrdude.conf -v -patmega168 -carduino -P/dev/ttyUSB0 -b19200 -D -Uflash:w:/home/dietrich/Projekte/Source/rust-arduino-blink/target/avr-atmega168/release/rust-arduino-blink.elf:e
    so its arduino nano but with atmega168
    rahix
    @rahix:matrix.org
    [m]
    hm, and I suppose you tried ravedude nano ....?
    enaut
    @enaut:matrix.org
    [m]
    ravedude nano --open-console --baudrate 57600 -P /dev/ttyUSB0 target/avr-atmega168/release/rust-arduino-blink.elf 
           Board Arduino Nano
     Programming target/avr-atmega168/release/rust-arduino-blink.elf => /dev/ttyUSB0
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
    enaut
    @enaut:matrix.org
    [m]
    I get that same error on the arduino IDE when I choose the default atmega328P
    Is ravedude automagically expecting arduino nanos to have the atmega328P chip?
    and thanks for your instant help!
    rahix
    @rahix:matrix.org
    [m]
    sorry, was afk just now
    yes, ravedude expects 328p because that's the only official nano ;)
    but I've head of the clones already, we should add proper support for them in ravedude & avr-hal
    jwagen
    @jwagen:matrix.org
    [m]
    Hmm, maybe it is the reset signaling that is not working. Try to push the reset button just before running the command
    rahix
    @rahix:matrix.org
    [m]
    well it does not make sense to try calling avrdude with -patmega328p for an ATmega168 anyway
    I'll hopefully get around to adding support in ravedude & avr-hal later this evening. If not, just ping me again enaut
    enaut
    @enaut:matrix.org
    [m]
    rahix wow thanks! :)
    jwagen I think reset is working just fine since the arduino stops the blinking pattern right when I press flash.
    rahix
    @rahix:matrix.org
    [m]
    enaut: please try Rahix/avr-hal#195 and report if that makes it work (I don't have any such devices on hand to test myself)
    I'll quickly add arduino-hal support as well in the meantime
    enaut
    @enaut:matrix.org
    [m]
    @rahix works nice as expected!
    rahix
    @rahix:matrix.org
    [m]
    great! I just pushed support for arduino-hal as well :)
    So if you point the git-revision in Cargo.toml to e72faada6bb7f67990216525aeb2132bbb3d53e9, you should be able to use it just like you'd do for the Arduino Nano (with ATmega328P)
    If you can test that as well, I'll merge the PR and add the board to the template repository
    enaut
    @enaut:matrix.org
    [m]
    sorry I'm not sure I can follow here... I installed ravedude from the git version and then I can use it. My current dependency on avr-hal looks like: [dependencies.arduino-uno] git = "https://github.com/Rahix/avr-hal" features=["arduino-nano"]
    what should work after that does not work before?
    rahix
    @rahix:matrix.org
    [m]
    add rev = "e72faada6bb7f67990216525aeb2132bbb3d53e9" and change the features to features = ["nano168"]

    what should work after that does not work before?

    as the two chips are almost identical, most likely nothing. But to keep everything clean I'd want to have the 168 version be handled separate, ontop of its own HAL layer. This means if there ever are any differences to care for, it is easy to differentiate the two.

    So more than supporting anything new, I just wanted to make sure I did not break anything with my changeset ;)
    enaut
    @enaut:matrix.org
    [m]
    I fail to be successfull... I added the small blink example to a git repository: https://github.com/enaut/temp-test
    ```
    ❯ cargo run
        Updating git repository `https://github.com/Rahix/avr-hal.git`
    error: no matching package named `arduino-uno` found
    location searched: https://github.com/Rahix/avr-hal.git?rev=e72faada6bb7f67990216525aeb2132bbb3d53e9
    perhaps you meant: arduino-hal
    required by package `rust-arduino-blink v0.1.0 (/home/dietrich/Projekte/Source/rust-arduino-blink)`
    what do I do wrong?
    rahix
    @rahix:matrix.org
    [m]
    hmm, wait a moment
    ooh, I totally missed that you're still using the old version of avr-hal... Sorry :(
    In that case, give me another minute - I'll prepare the new project template for the board, then you can just use that to test
    (We did some rather large changes to the crate-architecture of avr-hal recently... Maybe check https://github.com/Rahix/avr-hal#repository-structure to familiarize yourself with the new layout if you intend to update your own projects)
    enaut
    @enaut:matrix.org
    [m]
    OH thank you I suspected something like that!
    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: