crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
conplan has joined #rust-embedded
explore has joined #rust-embedded
<re_irc>
< (@orclev:matrix.org)> bah, I checked the closed issues for bitvec and there was a bug opened about this exact problem which was closed with essentially "won't fix" because any fix would be complicated for a variety of reasons. Sure would have been nice if that fact was documented. Oh well, one mystery down.
<re_irc>
< (@jamesmunns:beeper.com)> Have a link? that sounds like an interesting read
<re_irc>
< (@jamesmunns:beeper.com)> ahh, that makes sense
causal has quit [Quit: WeeChat 3.7.1]
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 252 seconds]
Foxyloxy_ has joined #rust-embedded
Foxyloxy_ has quit [Read error: Connection reset by peer]
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
darknighte has quit [Ping timeout: 246 seconds]
darknighte has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
neceve_ is now known as neceve
Shellhound is now known as Shell
<re_irc>
< (@explodingwaffle101:matrix.org)> that restriction with bitvec is the worst. i wouldn’t mind a nightly version that fixes it but i don’t think that’s how the maintainer does things (i mean, there’s not even an issue for it)
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 255 seconds]
cr1901_ has quit [Remote host closed the connection]
IlPalazzo-ojiisa has joined #rust-embedded
conplan has left #rust-embedded [Leaving.]
causal has joined #rust-embedded
dc740 has joined #rust-embedded
Foxyloxy has joined #rust-embedded
fooker has quit [Quit: WeeChat 3.5]
fooker has joined #rust-embedded
causal has quit [Ping timeout: 246 seconds]
causal has joined #rust-embedded
dc740 has quit [Read error: Connection reset by peer]
dc_740 has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 252 seconds]
Foxyloxy_ has joined #rust-embedded
yasu-n has joined #rust-embedded
yasu-n has left #rust-embedded [#rust-embedded]
dc__740 has joined #rust-embedded
dc_740 has quit [Ping timeout: 252 seconds]
Foxyloxy_ has quit [Read error: Connection reset by peer]
conplan has joined #rust-embedded
Foxyloxy has joined #rust-embedded
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
conplan has quit [Ping timeout: 252 seconds]
conplan has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
conplan has quit [Remote host closed the connection]
<re_irc>
< (@alex:matrix.sempto.net)> : Hey, one more thing with regards to Postcard: How would one serialize a "Option<&'a [u8;1024]"? Serde does not do const generics, and if I use the serde-big-array crate it fails with ``the trait "BigArray<'_>" is not implemented for `core::option::Option<&[u8; 1024]>```
<re_irc>
< (@alex:matrix.sempto.net)> * "the trait `BigArray<'_>` is not implemented for `core::option::Option<&[u8; 1024]>"
<re_irc>
< (@alex:matrix.sempto.net)> I think I can do simply "Option<&'a [u8]>" but then I lose access to #derive MaxSize
Foxyloxy has quit [Read error: Connection reset by peer]
<re_irc>
< (@jamesmunns:beeper.com)> hmm, I don't remember the answer off the top of my head, but this rings a bell as a _thing_ that isn't easy in serde
<re_irc>
< (@jamesmunns:beeper.com)> I know that doesn't help much, but maybe think about doing it slightly different, if that makes sense?
<re_irc>
< (@jamesmunns:beeper.com)> (hard to tell what to suggest without seeing your code)
<re_irc>
< (@alex:matrix.sempto.net)> Knowing not to try to do it this way is good to know already.
<re_irc>
< (@alex:matrix.sempto.net)> I think I'll try and use heapless::Vec instead of arrays.
<re_irc>
< (@alex:matrix.sempto.net)> Now that I think about it it is probably better since I don't always want to send 1024 bytes of data, just a maximum of 1024 bytes
Foxyloxy has joined #rust-embedded
cr1901 has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> That seems like a good idea!
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> hi room , meeting time again (europe is now in winter time...), agenda is https://hackmd.io/8hriIVW8T5CHQWKgtB8Rrw, please add anything you'd like to discuss or announce and we'll start in a few minutes :)
<cr1901>
Oh excellent, I actually _didn't_ miss the meeting :o
<cr1901>
Shame I've nothing to report
<re_irc>
< (@jamesmunns:beeper.com)> announcement: I hope you are all having a nice week and I hope none of you have missed a meeting (yet) due to the timezone mismatches
<re_irc>
< (@adamgreig:matrix.org)> I still have 117 unread emails after getting back from norway late last night lol, I haven't really kept up on embedded happenings the last five days or so
<re_irc>
< (@adamgreig:matrix.org)> right, let's start! I just have a couple of announcements, I noticed embedded-hal-async has a new alpha release out 🎉
<re_irc>
< (@adamgreig:matrix.org)> any other announcements from anyone?
<re_irc>
< (@jamesmunns:beeper.com)> oh, semi related, pcwalton is doing work to smash unnecessary memcpys in llvm16, I'd be interested to see how this affects embedded in a few months: https://twitter.com/pcwalton/status/1587282342174871552
<re_irc>
< (@jamesmunns:beeper.com)> might want to keep an eye out for when llvm16 lands for ub regressions
<re_irc>
< (@dkhayes117:matrix.org)> I noticed that I upgraded Rust nightly a couple of days ago, and my embassy project broke. The error message contained something about the embedded async hal. I don't have it in front of me right now, plus I didn't have the bandwidth (thesis work) to deal with it so I reverted back to "nightly-2022-09-22".
<re_irc>
< (@adamgreig:matrix.org)> hmm, 1.65 will bring LLVM15 for the first time too, which might introduce that bug in llvm15's objcopy for people with awkwardly aligned sections dumping to binary
<re_irc>
<zredshift> Something I often encounter is improperly annotated C functions where they expect a non-const pointer and length, but they don't actually manipulated the buffer. So I have to cast as "&T" to "*const T" to "*mut T", hopefully this won't become UB 😬
<re_irc>
< (@jamesmunns:beeper.com)> > So I have to cast as &T to *const T to *mut T, hopefully this won't become UB
<re_irc>
<zredshift> made my heart skip for a moment 😅
<re_irc>
< (@adamgreig:matrix.org)> just having the *mut seems ok, the spiciness is if they do try and write it I guess
<re_irc>
i checked in Ghidra, they don't write to it
<re_irc>
<zredshift> it's a pre-compiled static lib with an #include that doesn't "const" qualify it
<re_irc>
< (@adamgreig:matrix.org)> oh, and other embedded related changes in 1.65 include "arm4t-unknown-none" target support built-in
<re_irc>
<zredshift> I could supposedly patch the include
<re_irc>
< (@adamgreig:matrix.org)> it's not unusual for C authors to not bother specifying "const", huh
<re_irc>
<zredshift> * headers
<re_irc>
< (@adamgreig:matrix.org)> the only other point I had to mention this week is a new PR on svd2rust proposing swapping to methods for all register access, so instead of "uart.dr.write(...)" you'd have "uart.dr().write(...)", in https://github.com/rust-embedded/svd2rust/pull/692
<re_irc>
< (@adamgreig:matrix.org)> last call for any other topics to discuss this week :P
<re_irc>
< (@therealprof:matrix.org)> I'm all out. Was hoping to carve out some time for a newsletter push but failed. 😕
<re_irc>
< (@dirbaio:matrix.org)> : this is what chiptool does :D
<re_irc>
< (@dirbaio:matrix.org)> the main benefit is not syntax though
<re_irc>
< (@adamgreig:matrix.org)> yea, I think the intent is similar wrt opening up options for not just having things be memory mapped
<re_irc>
< (@dirbaio:matrix.org)> it's that it allows not generating any fields at all
<re_irc>
< (@dirbaio:matrix.org)> you just do pointer math and that's it
<re_irc>
< (@dirbaio:matrix.org)> currently svd2rust needs to generate the fields, calculate the paddings, handle overlapping fields as a special case... all that complexity is gone if you stop using fields
<re_irc>
< (@therealprof:matrix.org)> : How does that fare for code size in debug builds?
<re_irc>
(but fwiw svd2rust in debug builds is also Not Great℠, I haven't done any comparisons)
<re_irc>
< (@dirbaio:matrix.org)> : Not Great℠
<re_irc>
<zredshift> I wanted to ask, I noticed that all the embedded (e.g. embassy's blocking) mutexes are reentrant, and thus only allow access by reference requiring e.g. a "RefCell"
<re_irc>
what's stopping a non-reentrant implementation which would give you the nice affordances of e.g. "MutexGuard"?
<re_irc>
< (@grantm11235:matrix.org)> As in without any optimizations at all? I don't think anyone does that on purpose lol
<re_irc>
< (@dirbaio:matrix.org)> yeah in my experience unoptimized rust is always unusable, binaries don't fit in flash
<re_irc>
< (@dirbaio:matrix.org)> something something zero cost abstractions that are only zero-cost when building with optimizations
<re_irc>
< (@therealprof:matrix.org)> : Yeah, but each function call increases the suck factor by a lot.
<re_irc>
<zredshift> : it could be just basically "Mutex<RefCell<T>>" that does the borrow_mut for you
<re_irc>
< (@grantm11235:matrix.org)> zredshift: Sorry for the confusion, I was responding to and
<re_irc>
< (@therealprof:matrix.org)> : Well, it's the default and people are conditioned that for debugging you need optimisations turned off.
<re_irc>
<zredshift> : no problem, I wasn't confused haha
<re_irc>
<zredshift> I was the one who replied to the wrong person
<re_irc>
< (@therealprof:matrix.org)> ... not that you would actually need to outline function calls to trivial functions, the compiler might as well put the virtual function call into the debug info.
<re_irc>
<zredshift> the justification is very clear and valid, but sometimes you want better DX in exchange for maybe surprise panics :D
<re_irc>
< (@adamgreig:matrix.org)> since the RefCell methods are implemented on Mutex<RefCell<T>>, it's hopefully not much more work? you could even do like "type Mutex<T> = critical_section::Mutex<RefCell<T>>" in your crate if you wanted
<re_irc>
<zredshift> I use embassy's mutexes, which obtain the critical section token from within, I'll look if I can cook up something with them and these methods
<re_irc>
< (@dirbaio:matrix.org)> if you want to share data, "Mutex<Cell<T>>" is often enough, which avoids wasting memory for the "locked" flag in "RefCell"
<re_irc>
<zredshift> I love "Cell", but it has limitations
<re_irc>
< (@dirbaio:matrix.org)> if you want to share "async things" instead (such as an spi/i2c bus, or a driver) then you maybe want "embassy_sync::mutex::Mutex" instead, which does behave like "std::mutex::Mutex" (gives "&mut", to the contents, is not reentrant), and allows you to use ".await" while holding it
<re_irc>
< (@dirbaio:matrix.org)> and has better realtime properties because it doesn't hold interrupts disabled for the entire time it's locked
<re_irc>
<zredshift> mainly some types don't have an "uninhabited" value, so you have to use Option<T>, which may or may not waste up to a usize
<re_irc>
< (@dirbaio:matrix.org)> i'd only use "blocking_mutex::CriticalSectionMutex<RefCell<T>>" if you want to share "not-async things" which do require "&mut" which is somewhat rare in my experience
<re_irc>
<zredshift> and the two memcpys which may not be optimized away when you take out a value and return it
<re_irc>
<zredshift> e.g. "blocking_mutex::Mutex<Cell<heapless::String<32>>>"
<re_irc>
< (@dirbaio:matrix.org)> if you do really care about the memcpy then yes, do use "Mutex<RefCell<T>>"
<re_irc>
<zredshift> you replace it with "String::new()", and that would ostensibly not do a memcpy of "MaybeUninit" data
<re_irc>
<zredshift> but who knows
<re_irc>
< (@dirbaio:matrix.org)> then you get "&mut" to the contents and can use it in-place, but that's holding interrupts disabled which will impact interrupt latency
<re_irc>
< (@dirbaio:matrix.org)> it's just
<re_irc>
< (@dirbaio:matrix.org)> tradeoffs
<re_irc>
<zredshift> yeah, the async Mutex is good, but I don't need to await this type of computation, it's instantaneous
<re_irc>
< (@dirbaio:matrix.org)> there's no perfect mutex for every use case
<re_irc>
<zredshift> the refcell is instantaneous, is just some basic arithmetic, and the panicking branch is "#[cold]" IIRC
<re_irc>
< (@dirbaio:matrix.org)> and re "but sometimes you want better DX in exchange for maybe surprise panics": that's exactly what "Mutex<RefCell<T>>" does, so if you want that use that
<re_irc>
< (@dirbaio:matrix.org)> it would be more confusing to have two kinds of mutex: "NotReentrantMutex", "ReentrantMutex" :P
<re_irc>
<zredshift> :D
<re_irc>
< (@dirbaio:matrix.org)> this is why THE mutex is reentrant, and if you want "&mut" then you can combine it with "RefCell" :P
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 252 seconds]
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent is now known as Guest9391
emerent_ is now known as emerent
Guest9391 has quit [Killed (iridium.libera.chat (Nickname regained by services))]