<dirbaio[m]>
if you look at how HALs use it: you create a Transfer that owns the buffer, which starts DMA into it. You're free to move the Transfer (and therefore the buffer inside it) while DMA is running. So moving the buffer must not change the address of the actual data, or it'd be unsound
<dirbaio[m]>
and requiring that seems to be the original intent, with the StableDeref blanket impls
<dirbaio[m]>
but the safety docs don't mention it
<dirbaio[m]>
:|
<JamesMunns[m]>
> and self is not moved
<JamesMunns[m]>
Isn't that what `Pin` is for?
<JamesMunns[m]>
(did StableDeref predate Pin?)
<dirbaio[m]>
it's different, the intent is you can move the impl ReadBuffer, it just has to not move the actual data
<dirbaio[m]>
ie the data is required to be behind a pointer, not stored inline
<dirbaio[m]>
like, `&mut [u8; N]`, `std::Vec`, `std::Box` are valid `ReadBuffer`s
<dirbaio[m]>
but `[u8; N]` and `heapless::Vec` aren't
<JamesMunns[m]>
gotcha
<JamesMunns[m]>
yeah, the "smart pointer" can move but the "smart pointee" can't move
<dirbaio[m]>
exactly
<dirbaio[m]>
but i'm having a hard time explaining in that PR why it isn't sound
<dirbaio[m]>
because the docs are wrong I think??? 🤣
<JamesMunns[m]>
tho if the container doesn't move (i.e. it's a pin mut ref) it's also sound?
<JamesMunns[m]>
(tho - only in the absence of forget I guess?)
<dirbaio[m]>
yeah I guess you could make an alternate embedded-dma based on Pin
<dirbaio[m]>
that would be sound too
<JamesMunns[m]>
yeah, I haven't thought about e-dma in... a while 😅
<dirbaio[m]>
yeah...
<dirbaio[m]>
🫠
<JamesMunns[m]>
does h::vec even implement the "spare capacity" interface that stdvec does?
<JamesMunns[m]>
(actually idk if you are dma'ing into or out of the vec)
<dirbaio[m]>
yes
<dirbaio[m]>
you can use raw pointers and then unsafely set_len after the read is done
<dirbaio[m]>
but still
<dirbaio[m]>
it can't impl embedded-dma because it stores the data inline
<dirbaio[m]>
I guess `&'static mut heapless::Vec<u8, N>` could
<dirbaio[m]>
but at that point you can just use `&'static mut [u8]`
<JamesMunns[m]>
ah, from StableDeref:
<JamesMunns[m]>
> An unsafe marker trait for types that deref to a stable address, even when moved.
<JamesMunns[m]>
Gotcha, basically, hvec doesn't fulfill that contract
<dirbaio[m]>
would be good to fix the embedded-dma docs
<dirbaio[m]>
assuming I'm not missing something
<JamesMunns[m]>
Agreed it's not in the SAFETY section of that trait, but still as an unsafe trait I feel like it IS mentioned
<dirbaio[m]>
that's in StableDeref, but you can also impl ReadBuffer/WriteBuffer directly
<JamesMunns[m]>
"heapless vec does NOT deref to a stable address when moved, therefore it cannot impl StableDeref:
<JamesMunns[m]>
wait really
<dirbaio[m]>
so it shold be mentioned in the ReadBuffer/WriteBuffer docs
<JamesMunns[m]>
ahhh there's no bound on that
<JamesMunns[m]>
just on the blanket impl
<dirbaio[m]>
yeah
<JamesMunns[m]>
yep, agreed! The Read/Write buffer docs should get that same "types that deref to a stable address, even when moved" verbiage as `StableDeref`, or it should be a mandatory bound not just a blanket impl bound
<JamesMunns[m]>
(tho I guess as an unsafe trait you can just SAFETY doc it instead of making it mandatory)
<JamesMunns[m]>
<dirbaio[m]> "but at that point you can just..." <- I guess the benefit of the hvec impl would be automatic ptr + set_len handling
<dirbaio[m]>
it wouldn't be automatic anyway, you'd have to do it yourself
<dirbaio[m]>
so idk :D
<JamesMunns[m]>
ah the edma traits have no "cleanup"/"post callback" option either just "get ptr"
<JamesMunns[m]>
yeah, oof
<JamesMunns[m]>
(don't recommend mut slice tho - heapless is filled with uninit on new)
<JamesMunns[m]>
or recommend `as_ptr() into &mut [MaybeUninit<u8>]` or whatever
<JamesMunns[m]>
s/as_ptr/as_mut)ptr/
<JamesMunns[m]>
s/as_ptr/as_mut_ptr/
<dirbaio[m]>
HALs typically request `Word=u8` I think, not `MaybeUninit<u8>` (?)
<dirbaio[m]>
so ..
<dirbaio[m]>
¯\_(ツ)_/¯
<JamesMunns[m]>
I mean... you can make a `(*mut u8, usize)` soundly, just not `&mut [u8]`.
<JamesMunns[m]>
https://docs.rs/embedded-dma/latest/embedded_dma/trait.WriteBuffer.html makes no guarantee that the `*mut Word` is valid, tho it does say "Target must be a type that is valid for any possible byte pattern.", which, idk, is probably sound-ish, but `poison` is the 257th value of `u8` :p
<JamesMunns[m]>
(until we have freeze, which we don't)
<dirbaio[m]>
ahh true it might be OK if it uses just raw pointers
<JamesMunns[m]>
just saying - don't tell people to turn the spare capacity of a Vec into a `&mut [u8]` - that's UB
<JamesMunns[m]>
(unless you've explicitly filled the vec at least once, or do the init yourself 🙃)
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
linfax has quit [Ping timeout: 264 seconds]
marmrt[m] has quit [Quit: Idle timeout reached: 172800s]
xiugaze[m] has quit [Quit: Idle timeout reached: 172800s]
AdamHott[m] has quit [Quit: Idle timeout reached: 172800s]
SunClonus has joined #rust-embedded
AdinAck[m] has quit [Quit: Idle timeout reached: 172800s]
holo[m] has joined #rust-embedded
<holo[m]>
Hey, how to recieve different postcards/structs from socket, how can i know to which struct i should deserialize?
<diondokter[m]>
holo[m]: Put them in an enum and serialize/deserialize that
<diondokter[m]>
Then postcard does the work for you
<holo[m]>
diondokter[m]: Ahh will try, thanks
<JamesMunns[m]>
I'm also working on postcard-rpc, if you are specifically doing it so you can send a bunch of different commands/requests to a device, and to know what type it will respond with
<JamesMunns[m]>
(like instead of having a huge Request enum and Response enum)
<holo[m]>
JamesMunns[m]: I was looking on it but could not find example how to use it with TCP socket
<JamesMunns[m]>
I think cr1901 did, I don't have the link handy tho
<holo[m]>
when i was working with gRPC i just created there object with ip and port address and i could execute commandst just on that object.
<holo[m]>
JamesMunns[m]: ohh
<holo[m]>
cr1901: if you can send me link to example i will be grateful
<JamesMunns[m]>
Yeah, I haven't made it that easy yet, though I have that convenient now for a USB serial port.
<holo[m]>
JamesMunns[m]: Understand "Rome wasn't built in a day" 🙂
<JamesMunns[m]>
I'm very open to making more progress, if I can find someone to sponsor me :D
<JamesMunns[m]>
that said - tbh on a server system the difference between postcard and grpc won't matter AS MUCH as they do on a microcontroller.
<holo[m]>
i wast thinking too about capnproto there is writtein they support no_std too but it was too much complex still and dint have time to dig in to it yes, still didnt look so user friendly like gRPC
<JamesMunns[m]>
like, as much as I love postcard, and I would bet money postcard IS a bit faster and more efficient than gRPC, most applications are not ser/de bound (in RAM or CPU). So an optimization for sure, but maybe not a first one (and you lose some flexibility and compatibility for the cost of that perf!)
<holo[m]>
s/no_std/no\_std/, s/yes/yet/
<JamesMunns[m]>
but yeah, postcard-rpc is "you have rust on your PC and MCU already, why not make it easier to make them talk"
<holo[m]>
Waiting for final solution and for that example how to use it with tcp. Do you have maybe some roadmap? When can some feature be implmemented?
lulf[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has left #rust-embedded [Error from remote client]
MathiasKoch[m] has quit [Quit: Idle timeout reached: 172800s]
Socke has quit [Ping timeout: 255 seconds]
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
I need 10-pin Cortex Debug Connector cable, will this work and can I splice this into 2.54 pitch dupont cables to connect with SWDIO and SWDCLK on boards that don't have the 10-pin connector?
<AdamHott[m]>
* I need a 10-pin Cortex Debug Connector cable, will this work and can I splice this into 2.54 pitch dupont cables to connect with SWDIO and SWDCLK on boards that don't have the 10-pin connector?