ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
dne has quit [Ping timeout: 240 seconds]
dne has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <korken89> On the topic of "uninitialized", one this I should add to heapless (and maybe fix for James Munns bbqueue) is to allow to construct "const methods" directly on "MaybeUninit<Container>", like a "new_in_place(&mut MaybeUninit<Container>) -> &mut Containter". Turns out the compiler is not good at optimizing away the copy of a "MaybeUninit::write" if you have non-0 starting values.
<re_irc> <korken89> * thing
<re_irc> <korken89> It will happily place the container on the stack, and then copy it in - instead of constructing it in place
<re_irc> <korken89> Neeeeooooowwww says your stack space
limpkin_ is now known as limpkin
Guest2 has joined #rust-embedded
Guest2 has quit [Quit: Client closed]
<re_irc> help: consider further restricting this bound
<re_irc> |
<re_irc> <barafael> I'm updating a crate from embedded time 0.10 to 0.12. Compiler tells me at some point:
<re_irc> 31 | Clock: embedded_time::clock::Clock + embedded_time::clock::Clock,
<re_irc> | +++++++++++++++++++++++++++++
<re_irc> <barafael> that makes no sense :D if I do this, compiler asks for one more :D
<re_irc> <K900> You probably have a mix of versions
<re_irc> <K900> And those traits are from different versions
<re_irc> <barafael> what I want to do is "Delay::new(self.clock).delay(Milliseconds(200u32));" where "clock" is of type "Clock"
<re_irc> <chrysn (@chrysn:matrix.org)> When debugging a mix of versions, "cargo tree -d" is often helpful.
Guest2 has joined #rust-embedded
jringstad__ has joined #rust-embedded
jringstad__ has quit [Remote host closed the connection]
jringstad__ has joined #rust-embedded
jringstad__ has quit [Remote host closed the connection]
Amadiro has quit [Ping timeout: 272 seconds]
Amadiro has joined #rust-embedded
<re_irc> <dirbaio> korken89: "uninit.as_mut_ptr().write(Container::new_from_whatever())" usually does optimize well
<re_irc> <korken89> Nice, the next time I'm fighting with that I'll give it a try!
<re_irc> <dirbaio> constructing the thing then writing it to its final place with a raw ptr write usually optimizes well
<re_irc> <James Munns> korken89: I need to read back context, but bbqueue statics live totally in bss, at the cost of initialize-on-split
<re_irc> <dirbaio> only if there are no conditional branches or side effects between both :S
<re_irc> <James Munns> I also have a hack to do this for heapless mpmc queue in byte slab
<re_irc> <dirbaio> because the compiler can't let other code see the final memory location in a "half-written" state :(
<re_irc> <dirbaio> and this includes drops and panics
<re_irc> <James Munns> I start the struct in a weird-but-valid-state where all tracking vars are zero, in order to guarantee the whole struct is zero or uninit. Otherwise that single u32 “infects” the whole struct, which means a 64KiB struct would live in .data for ONE WORD of initialized data.
<re_irc> <James Munns> This does require atomic ops or a CS to handle safely though.
<re_irc> <James Munns> (bbqueue uses atomic polyfill for this, byteslab should but I havent switched it over yet.
<re_irc> <dirbaio> oh yeah I hate the .data bloat
<re_irc> <James Munns> Thats why I had to work around mpmc queues init
<re_irc> <James Munns> My slab allocator was ending up in .data because I use mpmc queue as a freelist
<re_irc> <James Munns> Which was bad, for a large allocator pool (slow to flash, waste of flash space)
gsalazar has joined #rust-embedded
<re_irc> <bradleyharden> Maybe someone here will know. A few years ago, I read a post about how to judge/rank APIs. The scale was essentially "impossible to use incorrectly" to "impossible to use correctly". I tried to dig up that post, but I can't find it at all. Does anyone know what I'm talking about?
<re_irc> If I remember correctly, it was a very bare bones website, and I think the API examples were in C.
<re_irc> <yruama_lairba> bradleyharden: there wasn't advice to make a good API ?
<re_irc> <bradleyharden> I don't remember. Maybe? I think it was mostly focused on showing examples from several different APIs
<re_irc> <bradleyharden> Both good and bad examples
<re_irc> <yruama_lairba> examples are already good indications
<re_irc> <yruama_lairba> but i guess Rust help greatly to prevent API missuse
<re_irc> <bradleyharden> I'm just trying to dig up that article. I've searched everything I can think of, but I can't find it. I was hoping someone here might know what I'm talking about
starblue has joined #rust-embedded
<re_irc> <thejpster> Can we do anything about the github teams spam?
<re_irc> <adamgreig> any ideas? it all gets spam filtered for me
<re_irc> <9names (@9names:matrix.org)> bradleyharden: Sounds like Rusty Russell's API ranking.
<re_irc> <9names (@9names:matrix.org)> There's also the complete list with negative values:
<re_irc> <9names (@9names:matrix.org)> Sounds like Rusty Russell's API ranking.
Guest2 has quit [Ping timeout: 256 seconds]
<re_irc> <justacec> This is a bit off topic, but I think that a few of you guys might know... So, I am pretty confused as to what the LoRa-E5 is. It says that it has a STM32WLE5JC MCU as well as a SX126X? But the STM32WLE5JC has a built-in radio right? Or is it that ST just merged a SX126X into their chip and are calling that the radio... Or did SeedStudio actually combine these two components. So confused... Does anybody have any...
<re_irc> ... experience with this?
<re_irc> <justacec> Here is a link to the item: https://www.seeedstudio.com/LoRa-E5-Wireless-Module-p-4745.html
gsalazar has quit [Ping timeout: 256 seconds]
<re_irc> <justacec> Ok, after sending my message a few minutes ago, I stumbled across this Gem: https://forum.seeedstudio.com/t/lora-e5-does-not-contain-a-semtech-sx1262/262389/15. So that kind of answers the question. The SX126X is imbedded in the STM32WLE5JC.
<Lumpio-> Wonder what kind of "legal action" they were going to take
<re_irc> <firefrommoonlight> > Or is it that ST just merged a SX126X into their chip and are calling that the radio.
<re_irc> > Yep
<re_irc> <firefrommoonlight> > Or is it that ST just merged a SX126X into their chip and are calling that the radio.
<re_irc> > Yep
<re_irc> <firefrommoonlight> ->
<re_irc> <yruama_lairba> hi, hi have a small refactoring issue with rtic. i want to put inside a lib functions taking a shared object, put unfortunatly, type of the shared object is known outside the app module.
<re_irc> <yruama_lairba> how to workaround that ?