avr-rust/Lobby

David

@drmorr0:matrix.org

[m]

so do we really need to do anything for nano support? or is it basically just already done?

David

@drmorr0:matrix.org

[m]

I just flashed the uno-adc.rs example to my Nano and it appears to be working fine

rahix

@rahix:matrix.org

[m]

sorry for only responding now David :/ I took another look, you're right I must've copied that from the old arduino-uno crate with its nano support. I should have taken a closer look before sending you off with this! Now, I think the following would be a good plan:

Add the arduino-nano feature flag to arduino-hal.
Make the ADC6 and ADC7 pins only available for nano, not for uno. I think we should hide them so people don't accidentally use them on a board where it is not supported.
Add an example crate for arduino-uno with just a blink and ADC example. I think for the rest we should just refer people to Arduino Uno, but it would be nice to a) have a blink example which you can just cargo run with zero setup, and b) show how the additional ADC pins can be used.

What do you think?

David

@drmorr0:matrix.org

[m]

Yep, sounds good to me!

Carl Peto

@carlos4242

I'm getting warnings that the atmega4809 is not a supported processor for llvm?

Carls-MacBook-Pro:src carlpeto$ "/Applications/Swift For Arduino.app/Contents/XPCServices/S4ABuildEngine.xpc/Contents/Resources/llvm-avr/llc" -O3 -march=avr -mcpu=atmega4809 -filetype=obj -function-sections -o ../build/atmega4809/register_PORTE.DIR.swft.o ../build/atmega4809/register_PORTE.DIR.swft.ll
'atmega4809' is not a recognized processor for this target (ignoring processor)
'atmega4809' is not a recognized processor for this target (ignoring processor)
'atmega4809' is not a recognized processor for this target (ignoring processor)
'atmega4809' is not a recognized processor for this target (ignoring processor)
'atmega4809' is not a recognized processor for this target (ignoring processor)
'atmega4809' is not a recognized processor for this target (ignoring processor)
'atmega4809' is not a recognized processor for this target (ignoring processor)
'atmega4809' is not a recognized processor for this target (ignoring processor)
'atmega4809' is not a recognized processor for this target (ignoring processor)
'atmega4809' is not a recognized processor for this target (ignoring processor)
Carls-MacBook-Pro:src carlpeto$ "/Applications/Swift For Arduino.app/Contents/XPCServices/S4ABuildEngine.xpc/Contents/Resources/llvm-avr/llc" -O3 -march=avr -mcpu=atxmega3 -filetype=obj -function-sections -o ../build/atmega4809/register_PORTE.DIR.swft.o ../build/atmega4809/register_PORTE.DIR.swft.ll
'atxmega3' is not a recognized processor for this target (ignoring processor)
'atxmega3' is not a recognized processor for this target (ignoring processor)
'atxmega3' is not a recognized processor for this target (ignoring processor)
'atxmega3' is not a recognized processor for this target (ignoring processor)
'atxmega3' is not a recognized processor for this target (ignoring processor)
'atxmega3' is not a recognized processor for this target (ignoring processor)
'atxmega3' is not a recognized processor for this target (ignoring processor)
'atxmega3' is not a recognized processor for this target (ignoring processor)
'atxmega3' is not a recognized processor for this target (ignoring processor)
'atxmega3' is not a recognized processor for this target (ignoring processor)

rahix

@rahix:matrix.org

[m]

you probably still need to set avrxmega3 IIRC

Carl Peto

@carlos4242

my llvm is about 6 months old I think

I did that with the second command? Is the format of my command wrong?

ha... just re-read my command

doh

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

Possibly related:
https://reviews.llvm.org/D97815
https://reviews.llvm.org/D97853

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]

rust-lang/compiler-builtins#400

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.

Where communities thrive

People

Repo info

Activity