Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    DoubleHyphen
    @DoubleHyphen
    So I'm trying to follow the steps proposed here
    https://creativcoder.dev/rust-on-arduino-uno
    What does that error mean?
    language item required, but not found: eh_personality
    I strongly suspect that it's my PC at fault. I'm using Debian, if it makes a difference.
    DoubleHyphen
    @DoubleHyphen
    Update: The problem was that I had to tell Rust to abort on panic. The debug version works now.
    The release version... does not.

    Compiling embedded-hal v0.2.4
    error: could not compile core

    Caused by:
    process didn't exit successfully: rustc --crate-name core --edition=2018 /home/froderick/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C panic=abort -C embed-bitcode=no -C metadata=ad26667fea11b055 -C extra-filename=-ad26667fea11b055 --out-dir /home/froderick/rust_arduino_blink/target/avr-atmega328p/release/deps --target /home/froderick/rust_arduino_blink/avr-atmega328p.json -Z force-unstable-if-unmarked -L dependency=/home/froderick/rust_arduino_blink/target/avr-atmega328p/release/deps -L dependency=/home/froderick/rust_arduino_blink/target/release/deps --cap-lints allow (signal: 11, SIGSEGV: invalid memory reference)

    Laris Qiao
    @laris
    Yes, that's bad guide
    you can try to add below config to your Cargo.toml
    [profile.dev]
    panic = "abort"
    lto = true
    opt-level = "s"
    
    
    [profile.release]
    panic = "abort"
    lto = true
    opt-level = "s"
    codegen-units = 1
    debug = true
    and please check the
    avr-atmega328p.json and add one line
    the max-atomic-width will fix latest nightly compile error
      "data-layout": "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8",
     "max-atomic-width": 8,
    Laris Qiao
    @laris
    One inline assembly question here:
    Laris Qiao
    @laris
    If operands do not fit into a single register, the compiler will automatically assign enough registers to hold the entire operand. In the assembler code you use %A0 to refer to the lowest byte of the first operand, %A1 to the lowest byte of the second operand and so on. The next byte of the first operand will be %B0, the next byte %C0 and so on.
    
    This also implies, that it is often neccessary to cast the type of an input operand to the desired size.
    
    A final problem may arise while using pointer register pairs. If you define an input operand
    
    "e" (ptr)
    and the compiler selects register Z (r30:r31), then
    
    %A0 refers to r30 and
    %B0 refers to r31.
    
    But both versions will fail during the assembly stage of the compiler, if you explicitely need Z, like in
    
    ld r24,Z
    If you write
    
    ld r24, %a0
    with a lower case a following the percent sign, then the compiler will create the proper assembler line.
    it looks like llvm don't support $A0 $A1 syntax
    I want to load 16-bit constant into a pair of register like r24:r25, it looks like no possible
    LDI $A0, lo(16-bit-cons) \n LDI $A1, hi(16-bit-cons)
    Carl Peto
    @carlos4242
    General AVR question. Sorry if this is too vague... I’ve got a Leonardo so I’m about to start programming it. The chip is the atmega32u4. My understanding is it’s basically the same core as the atmega328p, has the same instruction set, registers, etc. Just different interface hardware, like slightly different timers and different IO ports.
    So all I will really need to change is my hardware interface library, which does things like output to pin 13 or set a timer. I’ll need a new hardware library. But the compiler itself will work the same. Is that right?
    I think they’re both the avr51 core right?
    Rahix
    @Rahix
    @carlos4242: Yes, just HAL changes should be all. Ideally, you also pass -matmega32u4 to the linker but I'm not sure if that really is necessary as they are so similar
    Though do note that serial on the Leonardo is done via USB in the Arduino core while the Uno uses USART.
    Carl Peto
    @carlos4242
    yeah, passing -matmega32u4 to the linker is easy enough
    so I guess the issue there is if I send serial output on Leonardo, it won't show up on the standard serial monitor, I might need some tweaks there?
    Rahix
    @Rahix
    you need to connect an external USB to serial converter to D0 and D1
    (or implement CDC-ACM yourself :p)
    Carl Peto
    @carlos4242
    I don't even know what that is. :p)
    It's best efforts in my IDE right now I think. I'll find a way to program the Leonardo and add a serial cable directly to pins 0/1. One of the things I'll need to unhook is I'll need to make the serial window on my IDE configurable to one port and the programmer to another. Needs a little thought. Shouldn't be too hard.
    Kazuki Okamoto
    @kakkun61
    Hello. I am trying to compile code for AVR for the first time. I got the following errors. I followed “The AVR-Rust Guidebook”. Are there any workarounds?
    $ cargo build -Z build-std=core --target avr-unknown-gnu-atmega328 --release
       Compiling core v0.0.0 (/home/kazuki/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
       Compiling rustc-std-workspace-core v1.99.0 (/home/kazuki/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
       Compiling compiler_builtins v0.1.35
    error: could not compile `core`
    
    Caused by:
      process didn't exit successfully: `rustc --crate-name core --edition=2018 /home/kazuki/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C metadata=2eed32a902465f17 -C extra-filename=-2eed32a902465f17 --out-dir /mnt/h/Projects/avr-playground/led-blink/rust/target/avr-unknown-gnu-atmega328/release/deps --target avr-unknown-gnu-atmega328 -Z force-unstable-if-unmarked -L dependency=/mnt/h/Projects/avr-playground/led-blink/rust/target/avr-unknown-gnu-atmega328/release/deps -L dependency=/mnt/h/Projects/avr-playground/led-blink/rust/target/release/deps --cap-lints allow` (signal: 11, SIGSEGV: invalid memory reference)
    warning: build failed, waiting for other jobs to finish...
    error: build failed
    Laris Qiao
    @laris
    check my previous comments
    Emile Snyder
    @emilesnyder_gitlab
    @laris I too am having problems building the avr-rust/blink repo, getting SEGV that looks like @kakkun61's snippet from Oct 7. But when I look back at your older comments I don't see anything that looks like it would fix it? When I try to do 'cargo build -Z build-std=core --target avr-atmega328p.json' without the --release it seems to manage to build 'core' but fails the link stage complaining about undefined symbols for stuff like 'abort' and 'memcpy'. Any tips would be appreciated.
    Rahix
    @Rahix
    emilesnyder_gitlab: maybe you can try out the examples in avr-hal whether they compile for you?
    Kazuki Okamoto
    @kakkun61
    @bacongobbler created the same issue. avr-rust/blink#25
    Emile Snyder
    @emilesnyder_gitlab
    @Rahix ah, thank you! After cloning avr-hal, I can successfully build the blink example for uno board, both normal and --release build, so I'll work backwards from there trying to figure out what's different. Much appreciated!
    @kakkun61 ah, thank you for the link to the bug!
    Laris Qiao
    @laris
    Thank you Rahix
    Laris Qiao
    @laris
    @emilesnyder_gitlab I push modified template in here: https://github.com/laris/template-bin
    Emile Snyder
    @emilesnyder_gitlab
    @laris thanks!
    David
    @drmorr0

    Yup. That’s because the relocation is invalid and you are jumping to the wrong place.

    Hi, I am attempting to play around with async on AVR and I have come across the bug mentioned back in July around function pointers not working with llvm+AVR (thanks to @lights0123 for the super-useful blog post). I am wondering if there has been any progress made on this bug, or if there is an updated issue I could watch? I saw the original attempt had been abandoned

    this was the original PR https://reviews.llvm.org/D82536 (cc @aykevl @dylanmckay @shepmaster, I think you were all involved in that original conversation?)
    Alex Mikhalev
    @amikhalev
    I have submitted a more recent PR here https://reviews.llvm.org/D87631 . I haven't had time yet to address the comments on it yet
    David
    @drmorr0
    @amikhalev ++ that looks great
    I would offer to help but... I'm not totally sure my compilers knowledge is sufficient to do anything useful :\
    David
    @drmorr0
    @amikhalev actually I looked more closely at the PR. I think I could actually address all the comments on that except for the ones in the test case. if you happened to have some instructions on how you generated that, I could take a stab at fixing it up
    (of course you're also just welcome to do it yourself if you'd prefer, let me know if that's the case -- I'm in no big rush)
    matrixbot
    @matrixbot
    tunaxor hey there, sorry to bother, are there some arduino uno guides out there? I saw the repo in the avr org but felt quite lost by just staring at it
    Karl Thorén
    @kallemooo

    tunaxor hey there, sorry to bother, are there some arduino uno guides out there? I saw the repo in the avr org but felt quite lost by just staring at it

    I would look at the arduino-uno board from avr-hal and the examples for the arduino-uno board.

    It is a good starting point for rust on the arduino-uno.

    matrixbot
    @matrixbot
    daniel_tuna thanks I'll take a look at that
    Angel Daniel Munoz Gonzalez
    @AngelMunoz
    offtopic: pretty weird that matrixorg integration with gitter 😅