avr-rust/Lobby

Dylan McKay

@dylanmckay

what to do with avr-rust/rust repository. Wiki useful. issue trackers useful. new issues raised there is bad, better to raise on avr-rust/rust but we haven't actually made avr-rust/rust read only yet. considering moving the wiki into its own repository, archiving the repository thereby making issues read-only(???). maybe we should prune, port the important ones to upstream rust, then mark read only

Carl Peto

@carlos4242

Seems like sense?

Swift guys are pretty supportive of my effort in terms of giving advice. But not getting other people offering to fix stuff. And (most important) no promotion in the wider community. Oh well. V4 out soon. Big leap forward. :D

Dylan McKay

@dylanmckay

AVR support didn't quite make the deadline into today's nightly, but it should be in the next (2020-07-23)

Dylan McKay

@dylanmckay

https://avr-rust.com/
https://book.avr-rust.com/

Dylan McKay

@dylanmckay

it is now in today's nightly, all systems go

Dylan McKay

@dylanmckay

the upstreaming RFC has been closed - rust-lang/rust#44052

fork repository renamed - https://github.com/avr-rust/rust-legacy-fork - cannot set to read-only yet because it will lock all issues. the fork repository is now deprecated and all work should go into upstream-first from now on

Carl Peto

@carlos4242

Fantastic!! :))

What an exciting day!

Ayke

@aykevl

Cool!

I noticed a formatting issue at the bottom of this page: https://book.avr-rust.com/003-building-a-crate-for-avr.html

4 replies

Dylan McKay

@dylanmckay

note: github pages is very slow - after I update gh-pages branch, it takes the old version offline whilst jekyll builds..prebuilt html files. https://book.avr-rust.com/ has been out of commission for the last 10 minutes updating

Dylan McKay

@dylanmckay

TODO: need a place for people to raise general ecosystem issues (non-rustc, non crate specific) - feature requests etc

would be good to have a place to track them

Carl Peto

@carlos4242

agreed... otherwise there's nowhere for me to put bugs...

Or for Ayke to record them if they are just affecting the TinyGo frontend.

oh actually... https://bugs.llvm.org/enter_bug.cgi that's probably good enough?

Jake Goulding

@shepmaster

yeah, ideally with the reduced Rust/Swift/Go and the corresponding reduced LLVM IR

Carl Peto

@carlos4242

True. It’s quite buggy. The thing I like is you are the only people I have on gitter. When I get a message on gitter I know it’s AVR rust related, focused and not “chatter”! :)

Wojciech Niedźwiedź

@Niedzwiedzw

hey

so I can use standard rust and compile for say arduino from now on?

Wojciech Niedźwiedź

@Niedzwiedzw

how do I load it onto the board? :D I have arduino uno

Wojciech Niedźwiedź

@Niedzwiedzw

yeah, I did it!!

https://github.com/Niedzwiedzw/blink great job guys

such satisfaction :D

Carl Peto

@carlos4242

Should be a lot less niche now. We’ll see if a lot of folks get into it. Maybe you can post a video of you getting blink working. Like a simple howto. And tweet it to spread the word?

Jake Goulding

@shepmaster

@dylanmckay I finally remembered what the last fix i needed to get futures running — https://reviews.llvm.org/D82536

As the function pointer relocation of the executor vtable isn't correct

Jake Goulding

@shepmaster

For those who haven’t seen it https://book.avr-rust.com/

Ben Schattinger

@lights0123

I have UART and SPI working with async/await: https://github.com/lights0123/async-avr

I'll have a blog post about it published in a little while, but that runs on yesterday's nightly just fine

Ayke

@aykevl

Unfortunately, https://reviews.llvm.org/D82536 is invalid. I've abandoned it to indicate the current state. However, it may be good enough for you when you replace STT_NOTYPE with STT_FUNC.

Ben Schattinger

@lights0123

https://lights0123.com/blog/2020/07/25/async-await-for-avr-with-rust/

Plecra

@Plecra

Has anyone managed to get the https://book.avr-rust.com/002.1-installing-required-third-party-tools.html running on WSL?

Jake Goulding

@shepmaster

@lights0123 how are you avoiding the LLVM error that @aykevl and I are talking about? It makes the function pointers in the vtable incorrect.

Jake Goulding

@shepmaster

See my code here https://github.com/shepmaster/rust-arduino-blink-led-no-core-with-cargo/blob/master/src/main.rs

Jake Goulding

@shepmaster

@Plecra what problem (s) are you experiencing?

Plecra

@Plecra

I haven't tried it yet ^^ I was following the Rust-AVR book, and it doesn't have any instructions for using the toolchain on windows

I thought someone might've already given it a shot, and it'd be nice to hear how that went

Ayke

@aykevl

@Plecra WSL is basically just Linux, so any instructions for Linux should work

(there might be some exceptions around external devices)

Ben Schattinger

@lights0123

@shepmaster I just... don't? This works just fine for me:

#[export_name = "__vector_18"]
pub unsafe extern "avr-interrupt" fn __vector_18() {
    let mut led: atmega328p_hal::port::portb::PB5<Output> = unsafe { core::mem::zeroed() };
    led.set_high();
}

Ayke

@aykevl

@lights0123 it's possible the compiler managed to optimize away the indirection, this can happen especially when the program is very small

Compilers try to eliminate function pointer calls as function pointers are really hard to optimize.

Ben Schattinger

@lights0123

This works too

#[export_name = "__vector_18"]
pub unsafe extern "avr-interrupt" fn __vector_18() {
    test();
}

#[inline(never)]
fn test() {
    let mut led: atmega328p_hal::port::portb::PB5<Output> = unsafe { core::mem::zeroed() };
    led.set_high();
}

but I don't know how much it actually respects #[inline(never)]

Ayke

@aykevl

The set_high can still be inlined, for example

(I don't really know Rust but I'm assuming it works similar to C here)

Where communities thrive

People

Repo info

Activity