cr1901 has quit [Killed (NickServ (GHOST command used by cr1901_!~cr1901@2601:8d:8600:911:d897:2052:df35:5fc4))]
cr1901_ is now known as cr1901
PyroPeter has quit [Ping timeout: 252 seconds]
PyroPeter has joined #rust-embedded
<re_irc>
<@chrysn:matrix.org> Safety question: I have an object on the stack into which I want an ISR to mutate. So far, what I do is that I require a `&mut Pin<&mut>` to grant the interrupt access (ensuring the address will stay valid), and only access the data through the exclusive reference in a critical section.
<re_irc>
<@chrysn:matrix.org> Question is: What to I need to wrap the data with in my struct?
<re_irc>
<@chrysn:matrix.org> * Is it sufficient to just have it as a member? Justification: No &mut is held to it, only a &mut Pin<&mut> and that's not a &mut
<re_irc>
<@chrysn:matrix.org> * Should I wrap it in an UnsafeCell? Justification: That's what enables interior mutability
<re_irc>
<@chrysn:matrix.org> * Or is even an UnsafeCell not good enough? Justification: If having it as member is like having a &mut, then the UnsafeCell doesn't help because a &mut to an unsafe cell allows safe access to its interior.
neceve has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> How can you guarantee that the ISR won't fire when the object is no longer on the stack?
<re_irc>
<@thejpster:matrix.org> adamgreig: Should we push out TYIER today, or save it until about the 29th / 30th?
<re_irc>
<@adamgreig:matrix.org> Don't mind, anything else to add to the draft after my changes do you think? A "what we'll do next year" is probably optimistic at this point
<re_irc>
<@adamgreig:matrix.org> Maybe open the PR?
<re_irc>
<@chrysn:matrix.org> thejpster:matrix.org: The destructor of the inner type disables the ISR. (Actually it removes the pointer from a list of things the ISR does; removal happens in a critical section and the ISR itself checks that list only after having entered a critical section itself.)
<re_irc>
<@chrysn:matrix.org> (That destructor is also safe to use if the object hasn't been pinned in the first place, or was pinned but not started.)
<re_irc>
<@jamesmunns:beeper.com> chrysn what if I call `core::mem::forget` on your stack object?
<re_irc>
<@jamesmunns:beeper.com> and the destructor never runs?
<re_irc>
<@chrysn:matrix.org> It only gets activated when pinned, and once it's pinned, the destructor is guaranteed to run
<re_irc>
<@chrysn:matrix.org> (typically pinning happens at `pin_mut!()`, but pinning on the heap is an option for users as well).
<re_irc>
<@jamesmunns:beeper.com> Is it? I didn't think Pin guaranteed that, but I could be wrong
<re_irc>
<@chrysn:matrix.org> quoting pin module: "To make this work, not just moving the data is restricted; deallocating, repurposing, or otherwise invalidating the memory used to store the data is restricted, too. Concretely, for pinned data you have to maintain the invariant that its memory will not get invalidated or repurposed from the moment it gets pinned until when drop is called. Only once drop returns or panics, the memory may...
<re_irc>
<@jamesmunns:beeper.com> I ask because this was a Big Deal™️ while we were looking at embedded-dma.
<re_irc>
<@jamesmunns:beeper.com> thalesfragoso might be able to remember something I'm forgetting.
<re_irc>
<@chrysn:matrix.org> I missed most of that, but AIU things like io_uring need the very same drop-or-never-reuse guarantees that DMA needs, and pin caters for that.
<re_irc>
<@dirbaio:matrix.org> The Pin issue is it says "Drop must run before the memory is reused", not "drop must run"
<re_irc>
<@dirbaio:matrix.org> if the memory is not reused, it's OK to never call drop
<re_irc>
<@dirbaio:matrix.org> the problem is the pinned thing might borrow something else, so you can leak the pinned thing and THEN deallocate the borrowed thing
<re_irc>
<@dirbaio:matrix.org> then the irq fires, and then goes use-after-free on the borrowed thing
<re_irc>
<@dirbaio:matrix.org> jamesmunns:beeper.com: that's because `pin_mut!` shadows the original binding, you're leaking the pin but not the original binding
<re_irc>
<@jamesmunns:beeper.com> That does drop borrowed as expected tho
<re_irc>
<@dirbaio:matrix.org> the issue is you can get it to drop Borrowed without dropping Pinned
<re_irc>
<@jamesmunns:beeper.com> Ah, I thought the irq defuse was on Borrowed's destructor, not Pinned
<re_irc>
<@dirbaio:matrix.org> and Pinned = a dma Transfer struct, that stops DMA on drop
<re_irc>
<@dirbaio:matrix.org> imagine Borrowed = [u8; 1024], your DMA buf
<re_irc>
<@dirbaio:matrix.org> you can deallocate the buffer without stopping DMA 💀
<re_irc>
<@jamesmunns:beeper.com> I think that's what Chris was describing
<re_irc>
<@dirbaio:matrix.org> you can make it sound if you require `'static`
<re_irc>
<@dirbaio:matrix.org> but then you run into the same usability issues as embedded_dma
<re_irc>
<@gautam_agrawal:matrix.org> Hi, I am an embedded enthusiast. I am new to embedded rust , I wish to learn and contribute to it. Could any one please guide me from where I can get started.
<re_irc>
<@gautam_agrawal:matrix.org> Thank you.
<re_irc>
<@k900:0upti.me> Get started with what?
<re_irc>
<@newam:matrix.org> gautam_agrawal:matrix.org: Often the best way to learn is to pick a project :)
<re_irc>
<@k900:0upti.me> Embedded Rust what exactly?
<re_irc>
<@k900:0upti.me> "Embedded Rust" is very vague
<re_irc>
<@gautam_agrawal:matrix.org> k900:0upti.me: I have previously done everything on embedded systems using the already developed frameworks in c language , so I want to do bare metal programming in rust
<re_irc>
<@k900:0upti.me> What systems? What kind of programming?
<re_irc>
<@gautam_agrawal:matrix.org> k900:0upti.me: I have previously used STM32 , ESP32 (ESP-IDF) for my various projects
<re_irc>
<@k900:0upti.me> STM32 is a better target for Rust right now
<re_irc>
<@k900:0upti.me> ESP32 is somewhat supported, but requires a not-yet-upstreamed compiler fork
<re_irc>
<@gautam_agrawal:matrix.org> k900:0upti.me: so any suggestions where I can get started on this?
<re_irc>
<@k900:0upti.me> I'm still not quite sure what "this" is
<re_irc>
<@gautam_agrawal:matrix.org> k900:0upti.me: Is there any ongoing port of STM32 sdk to rust, I wish to learn things by picking an issue and solving it.
<re_irc>
<@k900:0upti.me> There is no "port of the STM32 SDK"
<re_irc>
<@k900:0upti.me> There are pure Rust STM32 HALs
<re_irc>
<@k900:0upti.me> But those are pretty feature complete at this point
<xnor>
happy to hear that
<xnor>
oops :)
<re_irc>
<@dngrs:matrix.org> I'd say there's still a lot of room for advanced timer usage for example (say, you want to use a timer to produce a PWM signal)
<re_irc>
<@dngrs:matrix.org> there's also the #stm32-rs:matrix.org room for focused discussion
<re_irc>
<@firefrommoonlight:matrix.org> I agree with newam
<re_irc>
<@firefrommoonlight:matrix.org> Come up with a project. Make it happen. Ask *specific* questions here when you run into trouble, are confronted with choices, or don't know how to proceed
<re_irc>
<@dngrs:matrix.org> I think so too, best way to proceed is to have a concrete goal
<re_irc>
<@gdamjan:spodeli.org> dirbaio:matrix.org: is ipv6 over BLE supported under (some kind of) Rust, on the nrf52...?
<re_irc>
<@gdamjan:spodeli.org> I think what I have is a nRF52832
cr1901 has quit [Remote host closed the connection]