$ 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
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
tunaxorhey 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
It is a good starting point for rust on the arduino-uno.
heapless::Vec, and the size of the vector is getting written with garbage data. I have traced it down to the fact that in an interrupt, two CPU registers aren't getting PUSH/POP'ed on the stack, and when the interrupt returns the code is assuming that the data those two registers is the size of the vector.