Guest7170 has quit [Killed (zinc.libera.chat (Nickname regained by services))]
emerent has joined #rust-embedded
fabic has joined #rust-embedded
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
funsafe has quit [Quit: funsafe]
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #rust-embedded
fabic has quit [Ping timeout: 246 seconds]
gsalazar has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc>
<gauteh> I'm getting some sporadic hard-faults, could they be caused by stack-overflows?
<re_irc>
<9names (@9names:matrix.org)> yes
<re_irc>
<gauteh> 👍️
j`ey has left #rust-embedded [#rust-embedded]
<re_irc>
<9names (@9names:matrix.org)> can recommend instrumenting your hardfault handler if you aren't certain what the cause is
<re_irc>
<gauteh> I have a breakpoint on it, but the debugger "fails to read address" of the frame
<re_irc>
<gauteh> by the way; working on a defmt-serial target: https://github.com/gauteh/defmt-serial totally super unsafe, but doing a tutorial in a couple of days with some people that don't have a debugger / rtt.
<re_irc>
<adamgreig> annoyingly conjure does seem like a good name for that particular version, and once it exists it's totally the obvious thing to use for the sorts of embedded ZSTs we talked about "conjure" for before
<re_irc>
<adamgreig> but i still don't like "conjure" for making a PAC struct up :P
<re_irc>
<James Munns> Which is handy, because it means I can do Very Cursed Things (https://github.com/tosc-rs/mnemos-alloc) on top of it, and miri can now tell me when I mess up :D
<re_irc>
<James Munns> Also, did matrix always support "[text](link)" syntax for chat messages? I've been writing a lot of markdown this week and did it without thinking, but now I'm kind of surprised it worked.
<re_irc>
<James Munns> I guess it supports other markdown'y things, so I shouldn't be THAT surprised.
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc>
<chuang> James Munns: it's a client behavior
fabic has quit [Ping timeout: 268 seconds]
jr-oss_ has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
jr-oss has joined #rust-embedded
fabic has joined #rust-embedded
dc740 has joined #rust-embedded
causal has quit [Quit: WeeChat 3.5]
dc740 has quit [Remote host closed the connection]
XMPPwocky has quit [Quit: You have been kicked for being idle]
<re_irc>
<Lachlan> I'm trying to frame messages using cobs into ring buffer, which means I don't have a contiguous slice to give to the encoder, which results in none of the cobs crates. Should I just write one?
<cr1901>
Is doubling the size of your ring buffer and keeping a copy of data in the second half an option to get a contiguous slice?
<re_irc>
<Lachlan> I'd prefer not
<re_irc>
<James Munns> Lachlan would bbqueue work for you?
<re_irc>
<James Munns> If you are only framing because of the ring buffer, bbqueue has a native "framed" mode which will handle message segmentation for you
<re_irc>
<Lachlan> I got my bespoke solution working, but I'll def use bbqueue in the future
<re_irc>
<Lachlan> Actually, I'd need a way to make the producer, consumer pairs statically to use it for this particular situation
<re_irc>
<James Munns> You can store the buffer statically, create the P/C pair at runtime, then give those away as resources at runtime
<re_irc>
<James Munns> OR you might be interested in the Super Spicy API that allows you to directly take the producer and consumer from the static whenever you feel like it!
<re_irc>
<James Munns> Because turns out I was doing enough locking already that the producer and consumer are already "Sync" safe, this just gives you the ability to basically manufacture as many producers and consumers as you want at any time
<re_irc>
<James Munns> it's still safe because you can only have one write grant or one read grant active at a time anyway
<re_irc>
<James Munns> (which, I guess makes it MPMC, but not really, because you can't actively be using it like that. More like an Arc<Mutex<Prod>> and Arc<Mutex<Cons>> without the heap allocations (and the locks atomic so everything is nonblocking)
<re_irc>
<James Munns> I guess I should probably "backport" that to upstream bbqueue
<re_irc>
<James Munns> just have a ".producer()" and ".consumer()" method on the buffer, which is statically allocated
<re_irc>
<James Munns> Plus this allows for arbitrary storage, which means you could technically use it for IPC on the desktop! I use it as the kernel-to-thread-io_uring-alike structure for my OS
Amadiro_ has joined #rust-embedded
Amadiro__ has quit [Ping timeout: 268 seconds]
<re_irc>
<Lachlan> James Munns: Oh cool! Yeah, I'd need to use this!
<re_irc>
<Lachlan> Would a "BbqQueue::new_split" that's const work?
<re_irc>
<James Munns> I dunno how to enforce it only gets split once
<re_irc>
<Lachlan> It would just return "(Producer, Consumer)", so couldn't be split more than once since the user wouldn't have access to the underlying bbqueue?
<re_irc>
<Lachlan> Apologies if that's not how the crate works, I'm not very familiar with it
<re_irc>
<James Munns> The problem is you need to have the bbqueue at a static location, since the prod/cons take pointers to it
<re_irc>
<James Munns> So you need to make the buffer separately, then take the pointers once it has a stable location
<re_irc>
<Lachlan> Ah
<re_irc>
<James Munns> (that's why it takes "&'static self")
<re_irc>
<Lachlan> If only ownership was a thing in statics haha
<re_irc>
<Lachlan> I guess the only way there would be to have a macro, but that's already implementable by the user
<re_irc>
<Lachlan> And you also can't do "static (A, B): ... = ...;"
<re_irc>
<James Munns> The address also changes when you return
<re_irc>
<James Munns> (like, technically you create the buffer in the stack frame, then return it and place it in the static)
<re_irc>
<James Munns> it's static so it's weird
<re_irc>
<James Munns> but also yeah
<re_irc>
<James Munns> (or const, rather)
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<ivii> I am want to learn embedded programming (mostly PWM with servo and DC motors) and I don't know which board to get. STM32 nucleo seems good. Any recommendations?
Amadiro__ has joined #rust-embedded
Amadiro_ has quit [Ping timeout: 240 seconds]
GenTooMan has quit [Read error: Connection reset by peer]
<re_irc>
<firefrommoonlight> Any development board would work for that
<re_irc>
<firefrommoonlight> Roll the dice
<re_irc>
<firefrommoonlight> follow your heart
GenTooMan has joined #rust-embedded
causal has joined #rust-embedded
<re_irc>
<adamgreig> I'll bring this up again at the meeting but for people watching the strict provenance story develop, https://github.com/rust-lang/rust/issues/98593 will be of interest