<re_irc_>
<@jacobrosenthal:matrix.org> the closure specifically is simply let blah = |arg1,arg2| { //some code here}; and the thing calls your closure and fills those args
<re_irc_>
<@jacobrosenthal:matrix.org> if its just one statement, you can leave off the {} which is why some of your pastes dont have it
<re_irc_>
<@jacobrosenthal:matrix.org> Just like functions, if you dont put a semicolon on the end of an expression, it gets returned, so the `w.iopeen().set_bit()` is being returned from the closure
<re_irc_>
<@firefrommoonlight:matrix.org> Translation of your except: Set the IOPEEN bit of the AHBENR register of the RCC register block. Set 0b01 to several MODER bits of the MODER register of the GPIOE register block.
<re_irc_>
<@firefrommoonlight:matrix.org> What this does: Enable the clock for GpioE pins, and configure several of them as outputs
<re_irc_>
<@firefrommoonlight:matrix.org> Also of note: the MODER commands are in the same closure since you can only write whole registers at a time. This allows you to set those 8 fields in a single write
<re_irc_>
<@barafael:matrix.org> What's the current state of wi-fi? Some new boards incoming, esp32c3, bl602, ...
<re_irc_>
<@sympatron:matrix.org> firefrommoonlight: dirbaio: How do you prevent race conditions on RCC if you modify it's registers without &mut RCC?
<re_irc_>
<@sympatron:matrix.org> I'm generally all for a simple API. Just curious about this.
<re_irc_>
<@sympatron:matrix.org> Although I think it could be useful to add this simpler API to a BSP. That way one could probably have a more arduino like experience without excluding use cases from the HAL.
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
<re_irc_>
<@therealprof:matrix.org> Ooh sweet. Rust 1.53 provides some very nice binary size improvements over 1.52.1.
fabic has joined #rust-embedded
<re_irc_>
<@altsegcat:matrix.org> oh cool
<re_irc_>
<@altsegcat:matrix.org> do you just use rustup to upgrade?
<re_irc_>
<@therealprof:matrix.org> Yes.
<re_irc_>
<@dirbaio:matrix.org> sympatron: bitbanding if the chip supports it, otherwise atomic instructions if the chip supports them, otherwise RMW in a critical section
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
cr19011 has joined #rust-embedded
cr1901 has quit [Ping timeout: 264 seconds]
<re_irc_>
<@9names:matrix.org> esp32c3: waiting for espressif to supply an SVD so they don't have to keep scraping data out of headers.
<re_irc_>
<@9names:matrix.org> bl602: bjoernQ has an initial proof-of-concept wifi build using the vendor-provided binary blob https://github.com/bjoernQ/bl602-wifi-rs
<re_irc_>
<@9names:matrix.org> as described in the readme, it's a bit painful to build since we don't have an upstream rv32imfc support. that's something i've been putting off due to lack of need, but now that we need to link C code it's kinda necessary.
<re_irc_>
<@9names:matrix.org> progress has been slow due to lack of interest + contributors. I suspect the c3 will not suffer as badly, given how active the esp32 community seems to be.
<re_irc_>
<@chemicstry:matrix.org> Does anyone know of a multi-core HAL implementation in rust? One that uses proper mutexes instead of interrupt free, which is not suitable for SMP. I'm writing a raspberry pi GPIO library and looking for inspiration. Thinking about going with `lock_api` route so it can work on any mutex implementation (be it...
<re_irc_>
... linux mutexes or baremetal atomic spinlocks)
fabic has quit [Ping timeout: 252 seconds]
<re_irc_>
<@firefrommoonlight:matrix.org> Sounds like a project
<re_irc_>
<@dirbaio:matrix.org> with embedded multicore you usually write independent firmwares for each core
<re_irc_>
<@dirbaio:matrix.org> because the cores are usually somewhat "different"
<re_irc_>
<@dirbaio:matrix.org> have access to different peripherals, or private ram/flash
<re_irc_>
<@chemicstry:matrix.org> I believe you are talking about heterogeneous multiprocessing such as those STM32 chips with one M4 and one M7 core? In that case yes, it is much more complicated. But I'm looking into raspberry pi 4 which has 4 cortex A72 cores and all of them share the same memory/peripherals. However, most of the...
<re_irc_>
... peripheral registers are not atomic read-modify-write and need locking to be used from different cores. In general the concept is simple, but I'm having trouble coming up with a convenient HAL API so was wondering if anyone has attempted this
<re_irc_>
<@ryan-summers:matrix.org> I used a RPI quad core in c/c++ a while back, and I opted for the approach of just offloading all cpu-heavy processing onto one core and leaving all peripherals / ethernet / etc. to be managed by the other. From what I understand, a very similar approach is used in medical devices as well
<re_irc_>
<@ryan-summers:matrix.org> Essentially, safety critical aspects get put in one core, and the other core manages non critical communication interfaces etc.
<re_irc_>
<@ryan-summers:matrix.org> But as dirbaio noted, there's often a fine division of responsibilities. That being said, my experience is still quite limited in this area as well
<re_irc_>
<@dirbaio:matrix.org> on rpis all the concurrency should be managed by Linux right?
<re_irc_>
<@ryan-summers:matrix.org> Not if you do it bare metal
<re_irc_>
<@dirbaio:matrix.org> ohhh
<re_irc_>
<@ryan-summers:matrix.org> Also, make sure you know that rapsberry pis are not open sourced
<re_irc_>
<@dirbaio:matrix.org> right, that'd affect both real linux-less bare metal, or the mmio hacks with /dev/mem etc
<re_irc_>
<@ryan-summers:matrix.org> Sometimes datasheets are obscure and/or hard to find
<re_irc_>
<@chemicstry:matrix.org> RPi always releases datasheets of their chips, but yeah they can be quite dry
<re_irc_>
<@ryan-summers:matrix.org> Maybe the CPU, but sometimes the USB/ethernet controller etc. aren't public
<re_irc_>
<@chemicstry:matrix.org> It has all GPIO/SPI/UART peripherals in the datasheet, but higher speed ones like USB/ethernet I believe use separate chips over PCIe, which can be closed source. And using PCIe bare-metal sounds horrible, although I don't have experience with that
<re_irc_>
<@dirbaio:matrix.org> I expect lots of controversy
<re_irc_>
<@dirbaio:matrix.org> use embedded-dma vs do the "you may not leak futures" vs gjve up on DMA
<re_irc_>
<@thalesfragoso:matrix.org> dirbaio: Something to talk about today
<re_irc_>
<@ryan-summers:matrix.org> chemicstry: I actually believe it talks SPI to the external USB controller, which is an integrated USB/ethernet controller. It's pretty interesting
<re_irc_>
<@ryan-summers:matrix.org> Or some other protocol, but I don't believe it's PCIe at all
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 258 seconds]
<re_irc_>
<@therealprof:matrix.org> ryan-summers: Wasn't it PCIe in the latest version (thus yielding 1GBit/s for the first time?).
<re_irc_>
<@therealprof:matrix.org> At least there was some hack desoldering some external peripheral which was connected over PCIe to actually give the Pi a PCIe port for other cards. 😉
<re_irc_>
<@therealprof:matrix.org> Ah, no, the USB3 controller is connected via PCIe.
<re_irc_>
<@adamgreig:matrix.org> hi @room , meeting time again! we'll start in 5min, agenda/sign-in is here: https://hackmd.io/1F73IWbJS9i7KnB7BbgBhQ, please add anything you'd like to discuss!
<re_irc_>
<@lachlansneff:matrix.org> I'm the person who made the new futures PR. Can I join the meeting?
<re_irc_>
<@lachlansneff:matrix.org> Or is it just here
<re_irc_>
<@eldruin:matrix.org> of course, the meetings are public
<re_irc_>
<@adamgreig:matrix.org> ok, let's get started, hi everyone!
<re_irc_>
<@adamgreig:matrix.org> no announcements from me this week, does anyone have anything to announce?
<re_irc_>
<@therealprof:matrix.org> Nope, what do we do with/about the newsletter?
<re_irc_>
<@adamgreig:matrix.org> I guess that's really blocked on me putting out this call for maintainers on cross and putting that into the blog, sorry... I'll get it finished tonight, otherwise let's just release as-is
<re_irc_>
<@adamgreig:matrix.org> there's a couple items leftover from last week but I think we can punt those to the end, the main item on this week's agenda is Lachlan Sneff's new futures-based traits PR on embedded-hal, https://github.com/rust-embedded/embedded-hal/pull/285
<re_irc_>
<@adamgreig:matrix.org> there's already been some discussion on the PR thread, but did anyone want to discuss some points more real-time here?
<re_irc_>
<@adamgreig:matrix.org> I think it's pretty clear we want some kind of futures-using traits in a `futures` module, at least!
<re_irc_>
<@lachlansneff:matrix.org> This was really just an initial pass at it, so I'm happy to change things or switch to a different approach!
<re_irc_>
<@adamgreig:matrix.org> thanks for getting the ball rolling!
<re_irc_>
<@dirbaio:matrix.org> my opinion based on what we've been doing in embassy is essentially what I commented there
<re_irc_>
<@dirbaio:matrix.org> essentially
<re_irc_>
<@dirbaio:matrix.org> "should traits allow for DMA impls?" my answer is a strong "yes"
<re_irc_>
<@dirbaio:matrix.org> this means all traits should take slices
<re_irc_>
<@dirbaio:matrix.org> word-by-word traits make no sense. They only made sense for `nb` because impls can't store state between polls, but futures can
<re_irc_>
<@thalesfragoso:matrix.org> another good question is to use or not to use embedded-dma, my vote is no ~_~
<re_irc_>
<@adamgreig:matrix.org> do you think there's any mileage in having both an unsafe and a safe trait, where the latter uses embedded-hal, and I guess provides an impl for the unsafe one?
<re_irc_>
<@dirbaio:matrix.org> yeah that's the thing
<re_irc_>
<@dirbaio:matrix.org> assuming we do want DMA
<re_irc_>
<@dirbaio:matrix.org> the million dollar question is "how"
<re_irc_>
<@thalesfragoso:matrix.org> adamgreig: the safe itself wouldn't be unsafe, only the type that implements it
<re_irc_>
<@dirbaio:matrix.org> 3. use naked slices and lobby the rust async WG to fix the leak issue so it becomes fully safe
<re_irc_>
<@dirbaio:matrix.org> 1. use embedded_dma
<re_irc_>
<@dirbaio:matrix.org> 2. use naked slices and accept it'll never be fully safe
<re_irc_>
<@dirbaio:matrix.org> ....??
<re_irc_>
<@adamgreig:matrix.org> in situation 2, is the trait method itself marked `unsafe`, since the caller must ensure the slice doesn't go away?
<re_irc_>
<@lachlansneff:matrix.org> dirbaio: I personally vote for #2. I don't think #3 is ever likely to happen.
<re_irc_>
<@dirbaio:matrix.org> embassy makes `new` unsafe
<re_irc_>
<@dirbaio:matrix.org> so by calling `new` you promise to not leak any future returned by any method
<re_irc_>
<@dirbaio:matrix.org> it's a bit iffy
<re_irc_>
<@adamgreig:matrix.org> `new` on the peripheral driver?
<re_irc_>
<@dirbaio:matrix.org> but it removes the need for having both safe and usafe traits
<re_irc_>
<@dirbaio:matrix.org> yeah
<re_irc_>
<@thalesfragoso:matrix.org> therealprof: I mean, I don't really have a vote in embedded-hal, but what is the question ?
<re_irc_>
<@adamgreig:matrix.org> that's then totally outside the scope of the trait methods, but I guess each implementor could do something similar
<re_irc_>
<@therealprof:matrix.org> What "use embedded_dma" entail? And why does no one seem to use it for this purpose?
<re_irc_>
<@thalesfragoso:matrix.org> use embedded-dma in the buffers types on the traits methods
<re_irc_>
<@dirbaio:matrix.org> oh also
<re_irc_>
<@therealprof:matrix.org> thalesfragoso: I'm curious why you wouldn't want to use it.
<re_irc_>
<@lachlansneff:matrix.org> What's wrong with having to use unsafe to call the method?
<re_irc_>
<@thalesfragoso:matrix.org> it's hard to use it, especially in async, because it requires ownership of the buffer and it's a bit awful to get it back
<re_irc_>
<@dirbaio:matrix.org> using embedded_dma means traits need FULL GATs, not just lifetime-only GATs.
<re_irc_>
<@thalesfragoso:matrix.org> Lachlan Sneff: safe APIs are better
<re_irc_>
<@dirbaio:matrix.org> and full gats aren't going to be stable anytime soon
<re_irc_>
<@thalesfragoso:matrix.org> dirbaio: oh yeah, forgot about this too
<re_irc_>
<@therealprof:matrix.org> And probably DMA only?
<re_irc_>
<@adamgreig:matrix.org> could we have an `unsafe` trait method today that takes naked slices, have a full-GAT-using (and nightly-only for the forseeable future) embedded-dma-using but safe trait alongside?
<re_irc_>
<@thalesfragoso:matrix.org> therealprof: not necessarily
<re_irc_>
<@adamgreig:matrix.org> and potentially in a further future we could make the naked slice method safe too, if someone patches leaking
<re_irc_>
<@thalesfragoso:matrix.org> adamgreig: Would someone implement the latter ?
<re_irc_>
<@adamgreig:matrix.org> yea, I guess maybe not. The latter could provide a default implementation of the former, though, right?
<re_irc_>
<@dirbaio:matrix.org> there's 2 problems with embedded_dma
<re_irc_>
<@dirbaio:matrix.org> 1. much less ergonomic. To allocate a `&'static mut` buffer you either need alloc or unsafe, and you need to keep passing it around to never lose it.
<re_irc_>
<@dirbaio:matrix.org> 2. full-GATs.
<re_irc_>
<@therealprof:matrix.org> Is there an upstream ticket open for that on which we've raised that we find this important?
<re_irc_>
<@thalesfragoso:matrix.org> adamgreig: no
<re_irc_>
<@adamgreig:matrix.org> huh, if you've got an embedded-dma object can't you unsafely get the underlying slice and pass it to the unsafe method?
<re_irc_>
<@thalesfragoso:matrix.org> but maybe interrupt based writting
<re_irc_>
<@adamgreig:matrix.org> a dumb implementation could just do a blocking write of the slice, safely
<re_irc_>
<@lachlansneff:matrix.org> Oh also, we should let upstream know that we need `min_type_alias_impl_trait` to be stabilized too.
<re_irc_>
<@adamgreig:matrix.org> (obviously it would be pointless, but clearly it's possible to implement the trait safely)
<re_irc_>
<@thalesfragoso:matrix.org> Lachlan Sneff: we could walk around that by not using `async {}` in the impl, but that is sad indeed
<re_irc_>
<@adamgreig:matrix.org> if you _don't_ make the trait method itself unsafe, most/every implementor has to do something to require the user use `unsafe` somewhere before calling the method, though, like embassy's unsafe `new`
<re_irc_>
<@thalesfragoso:matrix.org> adamgreig: also, with peripherals which have fifo, you could full the fifo, wait the interrupt, full again, better than blocking
<re_irc_>
<@lachlansneff:matrix.org> thalesfragoso: It seems like the feature works fine and there's already a `min_*` version of it, so stabilization is probably possible in the near future.
<re_irc_>
<@adamgreig:matrix.org> which seems like an easy thing to forget to do, leading to buggy implementations
<re_irc_>
<@adamgreig:matrix.org> and of course this is one of those issues where 99% of the time it would be fine anyway since you have to really try to leak stuff
<re_irc_>
<@thalesfragoso:matrix.org> Lachlan Sneff: yeah, I would most certainly like that
<re_irc_>
<@grantm11235:matrix.org> adamgreig: Only the implementations that use DMA, right?
<re_irc_>
<@lachlansneff:matrix.org> I was thinking these traits would be explicitly labeled as dma.
<re_irc_>
<@adamgreig:matrix.org> actually, I guess I don't know; how would a non-DMA implementation still hold on to the slice?
<re_irc_>
<@thalesfragoso:matrix.org> adamgreig: DMA is really tricky to get right already though... And I think almost everyone knows about the leak problem
<re_irc_>
<@thalesfragoso:matrix.org> at least everyone that implements a DMA abstraction in some HAL
<re_irc_>
<@thalesfragoso:matrix.org> adamgreig: on the returned future
<re_irc_>
<@thejpster:matrix.org> Is there a note I can read if I did know but may have temporarily forgotten?
<re_irc_>
<@adamgreig:matrix.org> at least technically we wouldn't be the ones releasing unsound code anyway, it would be a bug in the implementation side and we could be quite clear in our own docs about this common pitfall
<re_irc_>
<@thalesfragoso:matrix.org> it borrows both self (usually) and the slice
<re_irc_>
<@therealprof:matrix.org> dirbaio: Yes, but are they aware that there's an important usecase for embeddedd Rust which is even harder to solve without alloc?
<re_irc_>
<@adamgreig:matrix.org> ah, yea, ok
<re_irc_>
<@adamgreig:matrix.org> what stops the DMA version storing the slice in the returned future?
<cr1901>
I still am not sure about the DMA problem in blocking _or_ nonblocking code. I know there IS a problem, but I've not had the time to really grok it
<re_irc_>
<@dirbaio:matrix.org> I can think of 4 ways to impl this:
<re_irc_>
<@dirbaio:matrix.org> 1. just block reading the entire thing (never return Pending)
<re_irc_>
<@dirbaio:matrix.org> 2. Self-wake on each poll so you get immediately polled again, try to read bytes when polled.
<re_irc_>
<@dirbaio:matrix.org> 3. store a raw pointer to the buffer somewhere, set up an interrupt that reads into the buffer, wake the task when buffer fully read
<re_irc_>
<@thalesfragoso:matrix.org> adamgreig: it does, but you can leak the future and the dma won't stop and then you can use the buffer again
<re_irc_>
<@dirbaio:matrix.org> 1, 2 would *suck* though
<re_irc_>
<@adamgreig:matrix.org> thalesfragoso: right, of course, thanks
<re_irc_>
<@lachlansneff:matrix.org> Wait, since the future borrows the slice, leaking it would already prevent using it, right?
<re_irc_>
<@dirbaio:matrix.org> no, leaking the future clears the borrow on the slice
<re_irc_>
<@dirbaio:matrix.org> you can leak the future then get to use the slice again
<re_irc_>
<@lachlansneff:matrix.org> Oh, with `mem::forget`
<re_irc_>
<@richarddodd:matrix.org> I think it would be good to raise this issue with core Rust. The alternatives to relying on no leaks are not zero cost, and an affine type system can do what we want in theory
<re_irc_>
<@therealprof:matrix.org> Is there a way to implement it without `async` which we could later wrap with a true `async` version?
<re_irc_>
<@dirbaio:matrix.org> mem::forget, ManuallyDrop, Box::leak, Arc/Rc cycle, raw pointers
<re_irc_>
<@dirbaio:matrix.org> there's quite a few ways to leak
<re_irc_>
<@dirbaio:matrix.org> thankfully all super easy to avoid
<re_irc_>
<@thalesfragoso:matrix.org> richarddodd: It's known, not very easy to solve though
<re_irc_>
<@thalesfragoso:matrix.org> it involves changing the language, and they didn't change it even for the damn `Pin`
<re_irc_>
<@lachlansneff:matrix.org> Yeah, the ways to solve it would be pretty fragmenting to the ecosystem.
<re_irc_>
<@thalesfragoso:matrix.org> Lachlan Sneff: not really, you could have a `Leak` autotrait
<re_irc_>
<@lachlansneff:matrix.org> And you'd need to add `?Leak` to basically every type.
<re_irc_>
<@thalesfragoso:matrix.org> and have everything implement Leak, apart from `PhantomLeaked`
<re_irc_>
<@dirbaio:matrix.org> yup, Leak would fix this
<re_irc_>
<@dirbaio:matrix.org> except to be fully backwards compatible every existing type has to impl Leak
<re_irc_>
<@dirbaio:matrix.org> so it must be like Sized
<re_irc_>
<@dirbaio:matrix.org> where `fn foo<T>(t: T)` really means `fn foo<T: Sized + Leak>(t: T)`
<re_irc_>
<@dirbaio:matrix.org> and the "complexity cost" of adding another "magically implicit" trait like Sized was deemed too high
<re_irc_>
<@thalesfragoso:matrix.org> dirbaio: tbh it was a small conversation in zulip
<re_irc_>
<@thalesfragoso:matrix.org> maybe if we push it to a real meeting with the core team
<re_irc_>
<@dirbaio:matrix.org> yeah
<re_irc_>
<@dirbaio:matrix.org> maybe
<re_irc_>
<@dirbaio:matrix.org> who knows
<re_irc_>
<@richarddodd:matrix.org> It's so important to the embedded async use case.
<re_irc_>
<@lachlansneff:matrix.org> I really don't mind an `unsafe` dma method.
<re_irc_>
<@adamgreig:matrix.org> it's possible the magnitude of the utility for embedded use cases wasn't always clear though
<cr1901>
That's an understatement.
<re_irc_>
<@therealprof:matrix.org> adamgreig: Exactly my point.
<re_irc_>
<@adamgreig:matrix.org> Lachlan Sneff: but do you want two futures-based traits, one unsafe (for DMA) and one not? or would you only have unsafe futures, implicitly always for DMA?
<re_irc_>
<@thalesfragoso:matrix.org> making the new method unsafe seems to be the better option for now
<re_irc_>
<@thalesfragoso:matrix.org> and then we lobby
<re_irc_>
<@lachlansneff:matrix.org> No, just unsafe ones that are explicitly for DMA.
<re_irc_>
<@dirbaio:matrix.org> if we make it unsafe and then Rust ends up fixing the LeakProblem, we'll have to break the trait to remove `unsafe`
<re_irc_>
<@therealprof:matrix.org> thalesfragoso: Well, we might have missed the boat already...
<re_irc_>
<@lachlansneff:matrix.org> dirbaio: Call it `*_unchecked`.
<re_irc_>
<@adamgreig:matrix.org> if we make it safe, we still might need to break the trait to remove unsafe if we have to add bounds on `?Leak` or so?
<re_irc_>
<@dirbaio:matrix.org> renaming doesn't help, removing these is stil breaking
<re_irc_>
<@grantm11235:matrix.org> dirbaio: Yeah, but we won't have time to worry about a breaking change because we will be too busy celebrating
<re_irc_>
<@adamgreig:matrix.org> I guess we could always add a new safe trait for the fixed version which provides a default impl of the old unsafe one
<re_irc_>
<@adamgreig:matrix.org> (and deprecate the old one)
<re_irc_>
<@therealprof:matrix.org> jacobrosenthal: Well, we talked quite a bit with niko about async and embedded.
<re_irc_>
<@dirbaio:matrix.org> or just break it, provided it's still gated behind `unsafe`
<cr1901>
Perhaps name the "old trait" in a way that signifies "we intend to deprecate it"?
<re_irc_>
<@adamgreig:matrix.org> yea, if it's still unstable that would be ok
<re_irc_>
<@richarddodd:matrix.org> Since Niko came on this chat to ask us for input a while ago I think core Rust are interested in helping embedded.
<re_irc_>
<@therealprof:matrix.org> Not sure about helping but certainly they're looking for all kind of use cases and user stories. 😉
<re_irc_>
<@therealprof:matrix.org> Probably with the BYOB expectation. 😉
<re_irc_>
<@thalesfragoso:matrix.org> I think having the traits being safe and the types that implement them being unsafe is better
<re_irc_>
<@adamgreig:matrix.org> would that also mean that if/when rust gains a leak auto trait or equivalent, the types implementing them can just become safe, no change to the trait?
<re_irc_>
<@dirbaio:matrix.org> yup!
<re_irc_>
<@dirbaio:matrix.org> or not? maybe the GATs will need ` + ?Leak` added?
<re_irc_>
<@thalesfragoso:matrix.org> yeah
<re_irc_>
<@dirbaio:matrix.org> because otherwise they'll implicily be ` + Leak`
<re_irc_>
<@dirbaio:matrix.org> :\
<re_irc_>
<@thalesfragoso:matrix.org> we would need to break a little, but... everyone would be expecting that anyway
<re_irc_>
<@lachlansneff:matrix.org> They'd need to be `!Leak`, right?
<re_irc_>
<@thalesfragoso:matrix.org> not only expecting but hoping
<re_irc_>
<@richarddodd:matrix.org> dirbaio: Or `!Leak`
<re_irc_>
<@adamgreig:matrix.org> though by the same arguments we've made about how a 'safe' impl of these traits would be possible today (if it didn't use DMA), would it make sense to put `+ ?Leak` on these traits if it existed?
<re_irc_>
<@lachlansneff:matrix.org> `?Leak` would still allow leakable futures.
<re_irc_>
<@dirbaio:matrix.org> `+ !Foo` is not a thing, is it?
<re_irc_>
<@thalesfragoso:matrix.org> Lachlan Sneff: not necessarily, it would depend on the implementation, the futures using DMA would need to be !Leak
<re_irc_>
<@grantm11235:matrix.org> thalesfragoso: How would this work for drivers that use the trait? The driver wouldn't know anything about not leaking futures
<re_irc_>
<@dirbaio:matrix.org> allowing leakable futures is not a problem
<re_irc_>
<@dirbaio:matrix.org> the impl will make their futures not leakable if it's really using DMA
<re_irc_>
<@richarddodd:matrix.org> dirbaio: No that's negative bounds which has been discussed but not implemented
<re_irc_>
<@dirbaio:matrix.org> and then Rust won't let users leak the futures
<re_irc_>
<@lachlansneff:matrix.org> Wouldn't it be confusing if it's not guaranteed to use DMA?
<re_irc_>
<@lachlansneff:matrix.org> Very different performance characteristics
<re_irc_>
<@dirbaio:matrix.org> yeah
<re_irc_>
<@dirbaio:matrix.org> but that's an "implementation quality" issue
<re_irc_>
<@thejpster:matrix.org> Does this all go away if the Future owns a handle rather than a reference to a slice?
<re_irc_>
<@dirbaio:matrix.org> thejpster: that's exactly what embedded_dma is
<re_irc_>
<@thalesfragoso:matrix.org> thejpster: not a handle, it would need to own the real memory
<re_irc_>
<@thalesfragoso:matrix.org> if you only have a handle you can mem::forget the handle and them pop the stack, the memory would go away
<re_irc_>
<@thalesfragoso:matrix.org> and the DMA would go brrr on your new stack frame
<re_irc_>
<@lachlansneff:matrix.org> What if we required that it take a `Box<[u8], A>` instead of a regular slice?
<re_irc_>
<@lachlansneff:matrix.org> Maybe `Transfer` should be replaced with `Write`?
<re_irc_>
<@richarddodd:matrix.org> nrf SPI is implemented as exactly that: 2 slices
<re_irc_>
<@dirbaio:matrix.org> Lachlan Sneff: Write is just writing words. Transfer is writing AND reading.
<re_irc_>
<@dirbaio:matrix.org> they're different things
<re_irc_>
<@dirbaio:matrix.org> FullDuplex is the `nb` version of Transfer
<re_irc_>
<@therealprof:matrix.org> But they can't alias which depending on the implementation they might have to.
<re_irc_>
<@richarddodd:matrix.org> Ahh
<re_irc_>
<@dirbaio:matrix.org> yeah
<re_irc_>
<@adamgreig:matrix.org> oh, some hardware can only full-duplex in/out of a single buffer?
<re_irc_>
<@adamgreig:matrix.org> even with DMA?
<re_irc_>
<@adamgreig:matrix.org> is this nrf :p
<re_irc_>
<@dirbaio:matrix.org> it can either be single buffer, or a read + a write buffer
<re_irc_>
<@dirbaio:matrix.org> if we make it separate read + write buffers, the same change should be made to blocking::Transfer imo
<re_irc_>
<@dirbaio:matrix.org> nrf can tx/rx from separate buffers. I don't think any hardware is limited to single buffer
<re_irc_>
<@therealprof:matrix.org> adamgreig: I think I've seen that somewhere but I don't exactly remember where.
<re_irc_>
<@dirbaio:matrix.org> why is the current trait single-buffer?
<re_irc_>
<@adamgreig:matrix.org> afaik stm32 dma can only do two buffers
<re_irc_>
<@richarddodd:matrix.org> Ok the aliasing thing is hard, it doesn't match Rusy's many read xor 1 write
<re_irc_>
<@adamgreig:matrix.org> or, well, you could give it the same buffer in both spots and cross your fingers, maybe you can show it would be OK statically
<re_irc_>
<@dirbaio:matrix.org> "give the same buffer to both and pray" is how nrf is implemented, seems to work fine
<re_irc_>
<@dirbaio:matrix.org> but it's nowhere documented to be OK
<re_irc_>
<@richarddodd:matrix.org> dirbaio: Just x-ray the silicon?
<re_irc_>
<@adamgreig:matrix.org> you'd do that just to save RAM pressure on buffer size?
<re_irc_>
<@dirbaio:matrix.org> yea
<re_irc_>
<@dirbaio:matrix.org> single buffer means half ram usage
<re_irc_>
<@adamgreig:matrix.org> I guess makes sense since you probably don't need the tx data once you've sent it, yea
<re_irc_>
<@dirbaio:matrix.org> though it's sometimes annoying, maybe you want to send some data AND keep it around to send it later again
<re_irc_>
<@adamgreig:matrix.org> but yea, maybe
<re_irc_>
<@therealprof:matrix.org> And also it's just the way SPI works.
<re_irc_>
<@adamgreig:matrix.org> I think most SPI uses separate transmit and receive shift registers :P
<re_irc_>
<@dirbaio:matrix.org> the way SPI works is singlebuffer? why
<re_irc_>
<@therealprof:matrix.org> No, but same clock for read and write.
<re_irc_>
<@adamgreig:matrix.org> at best, same clock means you might expect it to be possible to use a single buffer
<re_irc_>
<@richarddodd:matrix.org> It would be sucky if you needed different methods for overlapping and non-overlapping buffers for DMA.
<re_irc_>
<@adamgreig:matrix.org> but it's not how the hardware peripherals tend to be designed in my experience
<re_irc_>
<@lachlansneff:matrix.org> Does SPI hardware supporting reading without writing?
<re_irc_>
<@dirbaio:matrix.org> yeah in hardware you get a "TX dma channel" and a "RX dma channel"
<re_irc_>
<@richarddodd:matrix.org> But I can't see how you can unify them without using raw pointers. Slices just don't do what we would need
<re_irc_>
<@adamgreig:matrix.org> I'd probably just say the trait takes a separate rx and tx slice
<re_irc_>
<@lachlansneff:matrix.org> dirbaio: Can we have a separate `Read` trait that only reads without writing then?
<re_irc_>
<@adamgreig:matrix.org> for the majority of use cases that's probably clearer
<re_irc_>
<@richarddodd:matrix.org> In NRF I think you can pass a null pointer and that side won't read/write anything (write the orc)
<re_irc_>
<@dirbaio:matrix.org> yeah
<re_irc_>
<@adamgreig:matrix.org> in stm32 dma I think it would be easy to accidentally screw up using the same buffer for both directions
<re_irc_>
<@adamgreig:matrix.org> e.g. if your msize was set different to psize, the dma will make one transaction to the buffer covering multiple spi words
<re_irc_>
<@therealprof:matrix.org> We're really bad when it comes to <censored>.
<re_irc_>
<@richarddodd:matrix.org> Wow s l a v e is censored
* re_irc_
@therealprof:matrix.org needs to read up on diversity friendly peripheral language...
<re_irc_>
<@adamgreig:matrix.org> it's unfortunate that "peripheral" means both the spi silicon inside the MCU and the remote IC you're talking to over the bus
<re_irc_>
<@lachlansneff:matrix.org> dirbaio: I'm a fan of adamgreig suggestion: Transfer and Exchange, respectively
<re_irc_>
<@dirbaio:matrix.org> I've never liked the name "Transfer"
<re_irc_>
<@dirbaio:matrix.org> isn't a write a "transfer" too?
<re_irc_>
<@adamgreig:matrix.org> maybe ReadWrite and Exchange
<re_irc_>
<@dirbaio:matrix.org> they're all different kinds of transfers
<re_irc_>
<@dirbaio:matrix.org> having one of them be named "transfer" is weird
<re_irc_>
<@lachlansneff:matrix.org> Can `Read` be implemented without actually sending any data on the bus?
<re_irc_>
<@dirbaio:matrix.org> you can't "not send data" since you always have the MOSI line, you need to put *something* in it
<re_irc_>
<@dirbaio:matrix.org> what peripherals do is just send zeros
<re_irc_>
<@dirbaio:matrix.org> or sometimes make it configurable what it sends
<re_irc_>
<@richarddodd:matrix.org> Iirc you have to read and write the same amount. You can send the orc byte when you don't want to write and discard reads
<re_irc_>
<@therealprof:matrix.org> In the end they're all transfers, but with different API. Read is Transfer(Garbage out), Write is (Transfer Garbage In) and so on.
<re_irc_>
<@adamgreig:matrix.org> nevertheless it can be nice to have the explicit read method to make it clear you don't care about what you're transmitting
<re_irc_>
<@richarddodd:matrix.org> orc register might be nrf specific
<re_irc_>
<@therealprof:matrix.org> adamgreig: What's the difference? Sounds like the same thing to me.
<re_irc_>
<@dirbaio:matrix.org> speaking of SPI, I opened this a few hours ago
<re_irc_>
<@adamgreig:matrix.org> therealprof: ReadWrite would be separate buffers, Exchange is just one buffer / operates in-place
<re_irc_>
<@grantm11235:matrix.org> adamgreig: Would that mean that the trait doesn't specify what data is sent out?
<re_irc_>
<@adamgreig:matrix.org> I don't think the trait would need to specify
<re_irc_>
<@dirbaio:matrix.org> it'd be "implementation defined, might be zero, might be configurable"
<re_irc_>
<@adamgreig:matrix.org> maybe in some implementations it's easy to use all-0 or all-1 or whatever
<re_irc_>
<@adamgreig:matrix.org> in any event the user doesn't care
<re_irc_>
<@lachlansneff:matrix.org> How about MaybeUninit for the read buffers?
<re_irc_>
<@adamgreig:matrix.org> if they needed all-0s they would use readwrite
<re_irc_>
<@grantm11235:matrix.org> That seems reasonable, assuming it is well documented
<re_irc_>
<@dirbaio:matrix.org> I can PR that if interested
<re_irc_>
<@dirbaio:matrix.org> I'd like to have "non-singlebuffer" readwrite in 1.0
<re_irc_>
<@lachlansneff:matrix.org> Should the `readwrite` and `readwrite_inplace` be in a single trait?
<re_irc_>
<@dirbaio:matrix.org> no
<re_irc_>
<@dirbaio:matrix.org> there are concerns some hardware can't do readwrite_inplace
bpye1 has joined #rust-embedded
<re_irc_>
<@dirbaio:matrix.org> (or can *only* do readwrite_inplace, though I think that'd be more rare)
<re_irc_>
<@lachlansneff:matrix.org> Is there a better name than `readwrite_inplace`?
<re_irc_>
<@adamgreig:matrix.org> `exchange` was my earlier suggestion for that
bpye has quit [Ping timeout: 264 seconds]
bpye1 is now known as bpye
<re_irc_>
<@adamgreig:matrix.org> wonder how much they make sense for these generic traits, vs end-user functions in a hal
<re_irc_>
<@adamgreig:matrix.org> would you write a driver to use the in-place version? I guess maybe if you had huge buffers
<re_irc_>
<@richarddodd:matrix.org> I quite like that name (readwrite_inplace) because it is descriptive, but I also like exchange
<re_irc_>
<@dirbaio:matrix.org> I find transfer/exchange confusing
<re_irc_>
<@dirbaio:matrix.org> multibuffer readwrite is arguably also "exchanging" data
<re_irc_>
<@adamgreig:matrix.org> yea, not strongly opposed to readwrite_inplace
<re_irc_>
<@adamgreig:matrix.org> exchange seems commonly used for this purpose
<re_irc_>
<@lachlansneff:matrix.org> Rust is all about being explicit, so lets use `inplace`
<re_irc_>
<@lachlansneff:matrix.org> I can add doc aliases
<re_irc_>
<@therealprof:matrix.org> Yeah, after explanation Exchange makes total sense to me, but no strong opinion either.
<re_irc_>
<@adamgreig:matrix.org> we're overtime for the meeting incidentally, so let's call it finished here, and thanks everyone for attending and the lively discussion!
<re_irc_>
<@adamgreig:matrix.org> of course please feel free to continue it :p
<re_irc_>
<@adamgreig:matrix.org> not sure what our conclusions were exactly though...
<re_irc_>
<@dirbaio:matrix.org> we didn't get to any wrt async, did we
<re_irc_>
<@adamgreig:matrix.org> it seems like using slices is a definite yes, probably don't put unsafe in the trait methods though that's a bit less clear
<re_irc_>
<@adamgreig:matrix.org> have four traits for r/w/rw/rwip, and extend that to the other types of traits
<re_irc_>
<@adamgreig:matrix.org> (for spi)
<re_irc_>
<@dirbaio:matrix.org> though "no full gats" prevents using embedded-dma
<re_irc_>
<@dirbaio:matrix.org> so I guess it's slices or slices
<re_irc_>
<@adamgreig:matrix.org> document that implementations will likely have to require unsafe somewhere if using dma
<re_irc_>
<@adamgreig:matrix.org> dirbaio: well it's definitely not words :P
<re_irc_>
<@richarddodd:matrix.org> Raise with core Rust both GATs and Leak auto trait
<re_irc_>
<@lachlansneff:matrix.org> I've been making the relevant changes to the PR during this conversation, so take a look at it.
<re_irc_>
<@richarddodd:matrix.org> As being very important for us
<re_irc_>
<@dirbaio:matrix.org> if we do that for async we should have it for blocking too
<re_irc_>
<@dirbaio:matrix.org> most async traits are 1:1 matches to blocking traits
<re_irc_>
<@lachlansneff:matrix.org> What should be do about nb
<re_irc_>
<@dirbaio:matrix.org> what do you mean about nb?
<re_irc_>
<@lachlansneff:matrix.org> Since nb was intended to be use for async operations, though it never really was, what's its future?
nexos has joined #rust-embedded
<re_irc_>
<@dirbaio:matrix.org> imo it should be deprecated eventually
<re_irc_>
<@dirbaio:matrix.org> but not now, only when async really is better established than nb. This means when async traits are stable, there's more adoption, etc
<re_irc_>
<@lachlansneff:matrix.org> Certainly, not anytime soon.
SomeWeirdAnon has quit []
<re_irc_>
<@firefrommoonlight:matrix.org> adamgreig: After you mentioned it here, that's how I'm handling it (Eg `unsafe fn write_dma()`)
<re_irc_>
<@dirbaio:matrix.org> yours is more unsafe though
<re_irc_>
<@dirbaio:matrix.org> yours is "user must ensure buffer lives during the transfer"
<re_irc_>
<@dirbaio:matrix.org> embassy is "user must not leak futures"
<re_irc_>
<@dirbaio:matrix.org> ie the borrow checker ensures the buffer lives during the transfer
<re_irc_>
<@firefrommoonlight:matrix.org> Good point