Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Dylan McKay
    @dylanmckay
    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!!
    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.
    Plecra
    @Plecra
    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
    @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)
    Ben Schattinger
    @lights0123
    yeah but wouldn't that function boundary of test produce the same error?
    Ayke
    @aykevl
    no, that's a direct call
    Ben Schattinger
    @lights0123
    it's a call within a call?
    Ayke
    @aykevl
    an indirect call is a function pointer, whenever you're storing a reference to a function and calling it elsewhere
    closures are also a kind of function pointer (not sure whether Rust has them tbh)
    Ben Schattinger
    @lights0123

    yeah it does have closures

    Ok, I get it now—is there a problem with the VTable for Futures? I've totally skipped over Wakers for now and am just busy-loop polling.

    Ayke
    @aykevl
    That's a bit out of my Rust knowledge, but normally a vtable is basically an array of function pointers that is usually stored as a global (for virtual functions in C++ for example). Calling a method from a vtable means doing an indirect call (as you're not directly calling the function, but loading the function address from the vtable and calling the function through that).