Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Carl Peto
    @carlos4242
    yep... that fixed it...
    Carls-MacBook-Pro:src carlpeto$ "/Applications/Swift For Arduino.app/Contents/XPCServices/S4ABuildEngine.xpc/Contents/Resources/llvm-avr/llc" -O3 -march=avr -mcpu=avrxmega3 -filetype=obj -function-sections -o ../build/atmega4809/register_PORTE.DIR.swft.o ../build/atmega4809/register_PORTE.DIR.swft.ll
    Carls-MacBook-Pro:src carlpeto$
    thanks so much @rahix:matrix.org
    :)
    glindstedt
    @glindstedt:matrix.org
    [m]

    Hello! 👋
    I just tried setting up a project for an attiny13, edited the target json file so cpu and mmcu = avr25, but getting this when I run cargo build -Z build-std=core:

       Compiling rustc-std-workspace-core v1.99.0 (/home/glindstedt/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
    error: ran out of registers during register allocation

    Anyone else run into this?

    hm, got a different error when I ran with --release
    LLVM ERROR: Not supported instr: <MCInst 296 <MCOperand Reg:1> <MCOperand Imm:15> <MCOperand Reg:43>>
    glindstedt
    @glindstedt:matrix.org
    [m]

    :point_up: Edit: Hello! 👋
    I just tried setting up a project for an attiny13, edited the target json file so cpu and mmcu = attiny13, but getting this when I run cargo build -Z build-std=core:

       Compiling rustc-std-workspace-core v1.99.0 (/home/glindstedt/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
    error: ran out of registers during register allocation

    Anyone else run into this?

    glindstedt
    @glindstedt:matrix.org
    [m]
    ok nevermind, debug build issue was fixed with optimizations added to profile.dev, and for the second issue I just found this which had a workaround at the end rust-lang/compiler-builtins#400
    Carl Peto
    @carlos4242
    This is a bit of a leading question but... does anyone know if llvm.global_ctors works properly in our AVR LLVM? I just started using clang to compile a .cpp file and the llvm back end isn't doing what I expect. It's creating an init_array section with pointers in there that seem to be twice what they should be (a standard AVR problem in various places we have had to fix).
    It looks like it's creating a relocation for that section that is of type R_AVR_16 but should be of type R_AVR_16_PM, no?
    (I reverted to compiling files that have initialisers with AVR-GCC instead for now.)
    ErikP0
    @ErikP0

    Hello,
    I'm having trouble doing floating point operations on my atmega328p (ardiuno nano). Casting f32 into ints, e.g. u8 is not
    working as expected:

    let dp = arduino_uno::Peripherals::take().unwrap();
    let mut pins = arduino_uno::Pins::new(dp.PORTB, dp.PORTC, dp.PORTD);
    let mut serial = arduino_uno::Serial::new(
            dp.USART0,
            pins.d0,
            pins.d1.into_output(&mut pins.ddr),
            57600.into_baudrate(),
        );
    
    let mut x: f32 = 11.45f32;
    loop {
        x += 0.1f32;
        let y: u8 = x as u8;
        ufmt::uwriteln!(serial, "cast is {}", y);
        arduino_uno::delay_ms(100);
    }

    The serial output is wrong

    cast is 0
    cast is 0
    ...

    I expected the compiler to generate a correct equivalent to
    a cast (byte)x in C. Replicating the same example in Ardiuno IDE in C, sends the expected values.

    Am I missing something here? I don't particularly care about speed or code size.
    Thanks

    rahix
    @rahix:matrix.org
    [m]
    This is a problem with the compiler, unfortunately. You can search the rust issue tracker, I don't have the link on hand right now
    ErikP0
    @ErikP0

    @rahix:matrix.org Hm, thanks. I found some issues, e.g. rust-lang/rust#77131 but they haven't been addressed yet. Do you by chance know a workaround?
    I though about linking floating point math operations and casts from C using cc in a buildscript, but I couldn't get it to link

    "avr-gcc" "-mmcu=atmega328p" "-Wl,--as-needed" "-L" ".rustup/toolchains/nightly-2021-01-07-x86_64-unknown-linux-gnu/lib/rustlib/avr-atmega328p/lib" "target/avr-atmega328p/debug/deps/rust_arduino-ca2d3e355b36d28f.test-0c5decc2c26b0640.35t0lcxenie65fwo.rcgu.o.rcgu.o" "-o" "target/avr-atmega328p/debug/deps/rust_arduino-ca2d3e355b36d28f.elf" "-Wl,--gc-sections" "-no-pie" "-L" "target/avr-atmega328p/debug/deps" "-L" "target/debug/deps" "-L" "target/avr-atmega328p/debug/build/rust-arduino-881a2491f4dee6ee/out" "-L" ".rustup/toolchains/nightly-2021-01-07-x86_64-unknown-linux-gnu/lib/rustlib/avr-atmega328p/lib" "-Wl,-Bstatic" "-Wl,--whole-archive" "-lf32math" "-Wl,--no-whole-archive" "target/avr-atmega328p/debug/deps/libcompiler_builtins-7cef1d6cf2eab31e.rlib" "-Wl,-Bdynamic" "-lgcc"
      = note: /usr/bin/avr-ld: target/avr-atmega328p/debug/build/rust-arduino-881a2491f4dee6ee/out/libf32math.a: member /target/avr-atmega328p/debug/build/rust-arduino-881a2491f4dee6ee/out/libf32math.a(math.o) in archive is not an object

    Maybe you can spot the error?

    rahix
    @rahix:matrix.org
    [m]
    I do not think there is a workaround right now... The best you can do is just not using floats - that's a good idea anyway on a target which does not even have hardware division. A good approach is using fixed point numbers instead, I think someone here made good experiences with the fixed crate for this
    ErikP0
    @ErikP0
    Thanks, fixed will do for my case :+1:
    Carl Peto
    @carlos4242
    Does anyone know what's happening with this issue? https://reviews.llvm.org/D95664?id=322354
    It's the fix for compiler errors like...
    LLVM ERROR: Not supported instr: <MCInst XXX <MCOperand Reg:1> <MCOperand Imm:15> <MCOperand Reg:53>>
    
      where XXX is the OpCode of either the STDWSPQRr instruction or the STDSPQRr instruction.
    I extracted the raw diff and added it onto my tree, which is basically llvm-project:main taken up to March 4th to get all the AVR fixes I can see. It seems to get rid of the above error but causes other unpredictable miscompiles when returning large structs from a function on the stack.
    Ayke
    @aykevl:matrix.org
    [m]
    Yeah I believe there are still bugs related to passing data on the stack
    Carl Peto
    @carlos4242
    yeah, it seems to be borked... got developers complaining to me they are getting totally unstable results with any large structs :(
    i_am_the_carl
    @i_am_the_carl:matrix.org
    [m]

    Good morning.
    I followed the avr book this morning and came across an issue.
    I managed to solve it but it does need to be reported.

    Using the latest version of nightly I can't build the compiler_builtins crate that builds with the core crate.
    I get the following error:

       Compiling compiler_builtins v0.1.43
    LLVM ERROR: Not supported instr: <MCInst 296 <MCOperand Reg:1> <MCOperand Imm:15> <MCOperand Reg:40>>
    error: could not compile `compiler_builtins`

    By switching to an older version of nightly (To be specific, 1.47.0-nightly (0820e54a8 2020-07-23)) and adjusting for it's different name for the avr target, I got those two crates to compile.

    At first I opened an issue for the AVR book because I thought it should say to do this... but is this actually a bug in rustc that needs to be fixed?
    Should I open issues in both repos?

    rahix
    @rahix:matrix.org
    [m]
    This is a known bug in LLVM, there is a patch awaiting review already
    rahix
    @rahix:matrix.org
    [m]
    i_am_the_carl
    @i_am_the_carl:matrix.org
    [m]
    Fantastic, then I'll just stand by.
    Carl Peto
    @carlos4242
    wait...what? Another Carl!
    Well that's just Carl tastic! Welcome!
    i_am_the_carl
    @i_am_the_carl:matrix.org
    [m]
    Haha, thank you.
    Jesús Hernández
    @jhg

    Hi, I'm playing with AVR boot section and trying to jump to program section with:

    const PROGRAM_START: u16 = 0x0000;
    let application: unsafe extern "C" fn() -> ! = unsafe { core::mem::transmute(PROGRAM_START) };
    unsafe { application() };

    Compiler is optimizing that removing the call when the address is 0x0000, that as far as I know is just the start of the program section, then where I want to jump. Also I tried to do with inline asm but the compiler complain about that target does not support inline asm.

    Is there some way to do this? or is this a compiler error?

    jwagen
    @jwagen:matrix.org
    [m]
    Have you tried the llvm_asm macro. That was the old way of dooing inline assembly in rust.
    Jesús Hernández
    @jhg
    No, I didn't, I'll try. Thanks! Anyway, is normal the compiler delete the call? OR even if llvm_asm macro works it must be a issue in the compiler github?
    jwagen
    @jwagen:matrix.org
    [m]
    I dont't know. Yes it does sound a bit strange. My knowlage what is and is not allowed by the compiler to optimise is limited.
    Which rustc version are you using?
    Jesús Hernández
    @jhg
    toolchain: nightly-2021-01-07 (because an regresion)
    rustc 1.51.0-nightly (c2de47a9a 2021-01-06)
    @jwagen:matrix.org thanks! llvm_ams works well (at least until have asm macro or the compiler does not delete the call)
    Ayke
    @aykevl:matrix.org
    [m]
    I think there is a good chance the compiler assumes calling a nil pointer is undefined behavior, just like dereferencing a nil pointer is undefined behavior.
    Compilers usually respond to undefined behavior by deleting code.
    Using inline assembly seems like a good workaround to me. The compiler won't look at that.
    Aidan
    @quantumferret

    Hi, so I've been trying to use the milllis() function from Rahix's arduino uno millis() example, and I've run into the issues regarding u32 types acting like u16 types.

    I've tried setting overflow-checks = false and debug-assertions = false under the compiler_builtins package in Cargo.toml, to no avail, as well as setting "no-builtins": true in avr-atmega328p.json.

    Is using two u16s and manually handling overflow still the best workaround for this? Are there other tweaks to the target json file that would be worth trying? I've been digging into linker configuration and the like, but my knowledge of the topic is very limited.

    rahix
    @rahix:matrix.org
    [m]

    Is using two u16s and manually handling overflow still the best workaround for this?

    I think it is, unfortunately.

    Aidan
    @quantumferret
    Darn, well it's good to know for sure. Would using a struct to hold the u16 pair help with the ergonomics? I'll likely have to use millis() or micros() as a seed for a (pseudo)random number generator, since any button press or release should perturb the generator's state.
    Aidan
    @quantumferret
    Hrmm, would I actually need to care about millis() for that purpose, if using Rust? I'm going off of an assignment specification that's intended for use with Arduino's C++ and the Arduino IDE, so perhaps there is a cleaner approach available since I'm free from the Arduino language's clutches.
    rahix
    @rahix:matrix.org
    [m]
    Maybe just use a 16bit timer and have it count up as fast as possible. Whenever a button is pressed you read out the current value which is going to be quite unpredictable this way.
    riskable
    @riskable:matrix.org
    [m]
    Is nightly-2021-01-07 still required for all the avr stuff?
    rahix
    @rahix:matrix.org
    [m]
    yes...
    Aidan
    @quantumferret

    I tried again to make millis() use u32 and just didn't write anything to Serial, but instead displayed the count in seconds on a 7-segment display, and it's counting well past 65 seconds now, despite that meaning that MILLIS_COUNTER should be holding a value much larger than a u16 could store.

    Stupidly, I don't think I actually tried using u32 without writing to Serial before, and this time around I also added "linker-flavor": "gcc" and "no-builtins": true to `avr-atmega328p.json, which may or may not have helped. I'm cautiously rejoicing now.

    rahix
    @rahix:matrix.org
    [m]
    the problem might be in the code which converts the u32 to a string then
    i.e. some intrinsic which is called from that algorithm might not behave as it should
    Aidan
    @quantumferret
    so the u32 miscompilation likely comes from ufmt, and is itself a symptom of the linking issues involving compiler-builtins/LLVM?
    rahix
    @rahix:matrix.org
    [m]
    more likely compiler, not linker, but yes, so it seems