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
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
Amadiro_ has joined #rust-embedded
Amadiro has quit [Ping timeout: 268 seconds]
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
explore has joined #rust-embedded
rardiol has quit [Ping timeout: 245 seconds]
tafa has quit [Quit: ZNC - https://znc.in]
tafa has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
Amadiro_ has quit [Ping timeout: 268 seconds]
explore has quit [Quit: Connection closed for inactivity]
brazuca has quit [Quit: Client closed]
cr1901 has quit [Ping timeout: 255 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <eldruin> PSA: "linux-embedded-hal" 0.4.0-alpha.3 (https://github.com/rust-embedded/linux-embedded-hal/releases/tag/v0.4.0-alpha.3) release is out, now using "embedded-hal" 1.0.0-alpha.8
Amadiro has joined #rust-embedded
Amadiro has quit [Max SendQ exceeded]
Amadiro has joined #rust-embedded
cr1901 has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
brazuca has quit [Quit: Client closed]
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
cr1901_ is now known as cr1901
brazuca has quit [Quit: Client closed]
<cr1901> James Munns: When you're not busy, do you have time to talk about our lord and savior bbqueue (I have a few implementation questions)?
causal has quit [Quit: WeeChat 3.6]
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
brazuca has quit [Quit: Client closed]
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
brazuca has quit [Quit: Client closed]
Guest14 has joined #rust-embedded
<re_irc> <cagrisk> Is there any having problem with GDB debugging STM32 on Windows? My specific problem is; auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path C:\Users\XXX\Workspace\RustEmbedded\iXXX_stm32f103rb.gdbinit line to your configuration file " $HOME/.gdbinit".
Guest14 is now known as brazuca
<re_irc> <cagrisk> I added as the warning said, restarted terminal but gdb doesn't take /gdbinit file in home directory of windows system.
brazuca has quit [Quit: Client closed]
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
dc740 has joined #rust-embedded
<cr1901> James Munns: ping?
dc740 has quit [Remote host closed the connection]
dequbed has quit [Quit: bye!]
<re_irc> <James Munns> cr1901 somethings up with the bridge
dequbed has joined #rust-embedded
<re_irc> <James Munns> I can see your message in the logs, but not on matrix (CC adamgreig)
<cr1901> James Munns: Thanks for the update, I'll msg in DM (although what I'm asking is useful advice for #rust-embedded in general)
dne has quit [Remote host closed the connection]
<re_irc> <adamgreig> Ugh, thanks for ping, will check in a few mins
<cr1901> Or maybe I'll do it here if you keep the logs open :P
dne has joined #rust-embedded
jamesmunns-irc has joined #rust-embedded
<cr1901> Ooor this works lol
<jamesmunns-irc> Heyyo @cr1901
<cr1901> Hello... I'll try not to be too long so you're not stuck on awful IRC for long :P
<jamesmunns-irc> So what's up w/ bbqueue?
<jamesmunns-irc> I don't mind IRC on my PC, but matrix IS nicer :D
<agg> great, it works for you? lol
<agg> and for me...
<agg> just doesn't like cr1901
<jamesmunns-irc> :D
<cr1901> Siiiigh
<agg> lemme bounce it
<cr1901> Uhhh, short version: I wrote an lock-free queue for AT2XT after someone suggested that I could remove the RefCell if I did that. It works (as in compiles) and I want to maybe port bbqueue to msp430 as a nicer solution.
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
<cr1901> but I have a few questions
<cr1901> Test for bridge
<jamesmunns-irc> (no bridge from cr1901 yet
<cr1901> Why is it filtering me T_T?
<jamesmunns-irc> So, you probably could port it to msp430
<jamesmunns-irc> msp430 doesn't have atomics tho, but you could do it with a critical section
<agg> weird, I can't remove your proxy user, matrix says you're not in the room :/ and restarting the bridge or the homeserver hasn't helped
<agg> but what's changed, it was working fine with your user before
<cr1901> Oh ffs
cr1901 has left #rust-embedded [Leaving]
<jamesmunns-irc> on the matrix side I can see cr1901 and cr1901_
cr1901 has joined #rust-embedded
<cr1901> How about now?
<jamesmunns-irc> nope
<jamesmunns-irc> matrix side sees cr1901 and cr1901_
<jamesmunns-irc> not sure if that tells adam anything
<agg> I don't see cr1901_ on the matrix side, but are you able to remove either of them from the room jamesmunns-irc?
<agg> weird, that user didn't even show on my user list
<jamesmunns-irc> I kicked the cr1901_
<agg> refreshing element lol
<jamesmunns-irc> but it still says cr1901 isn't in the room
<cr1901> Hmmm well, worry about it a bit later
<cr1901> This wouldn't be happening if Libera actually added their bridge
<jamesmunns-irc> but yeah, you can look at the current impl that supports thumbv6
<cr1901> jamesmunns-irc: msp430 does have atomic fetch_add and fetch_sub
<jamesmunns-irc> you'll need to do a similar dance with msp430's critical sections and stuff
<cr1901> it's the normal add and sub insns b/c they can modify memory directly and msp430 will not interrupt a currently running insn
<jamesmunns-irc> you need add, sub, and swap
<cr1901> Yea, that's my question... can we get rid of swap?
<cr1901> My queue impl doesn't need it
<cr1901> But I _think_ I know why you have it
<jamesmunns-irc> yeah, it's basically acting like a mutex in three places
<cr1901> Is it because you can't know at compile time whether you'll try to produce/consume while produce/consume is in process?
<jamesmunns-irc> if you proooooomise to never split twice, or try and take a read/write grant dupe, you'll be okay
re_irc has left #rust-embedded [#rust-embedded]
<jamesmunns-irc> yeah, it's so you can hold on to a grant past a single borrow
re_irc has joined #rust-embedded
crabbedhaloablut has quit [Write error: Connection reset by peer]
<cr1901> What do you mean "past a single borrow"?
crabbedhaloablut has joined #rust-embedded
<jamesmunns-irc> like, you can borrow the consumer, take a grant, and end the borrow of the consumer
re_irc has left #rust-embedded [#rust-embedded]
<jamesmunns-irc> and the grant is still valid
<cr1901> So my queue is 'static. It doesn't have a concept of "grant past a single borrow" I don't think
<cr1901> You could in principle borrow it from multiple interrupts, and the queue will not work correctly. But that's not memory-unsafe
<cr1901> it's just wrong :P
<jamesmunns-irc> so actually with those guards
<jamesmunns-irc> the producer and consumer CAN be sync
<jamesmunns-irc> (though: the grant will fail if one is active already)
re_irc has joined #rust-embedded
<agg> (test test)
<cr1901> test?
<jamesmunns-irc> beep boop
<re_irc> <agg (@agg:psion.agg.io)> yay, i see you cr1901
<cr1901> awesome
<cr1901> things work now
<jamesmunns-irc> I don't see his messages in matrix?
<jamesmunns-irc> (I see ours tho)
<re_irc> <adamgreig> oh no... I do on one homeserver but not the other?????
<re_irc> <adamgreig> what on earth, lol
<re_irc> <James Munns> oh noooo
<re_irc> <James Munns> (fwiw I'm on the "beeper.com" homeserver)
* cr1901 is considering prodding a Libera admin to fix this shit once and for all. It's been over a year now.
<agg> if you can convince them to set up the ircservices bridge please do
<jamesmunns-irc> but yeah, you'll need to either: keep/emulate the swaps, OR be very very careful
matrixbridge has joined #rust-embedded
matrixbridge has left #rust-embedded [#rust-embedded]
<cr1901> Why are the producer and consumer not sync without those guards?
<agg> "Failed to make link: This room has 1072 users, but the maximum for a bridged room is 100." :'(
<jamesmunns-irc> because otherwise they wouldn't be re-entrant safe
<cr1901> Well, my queue isn't reentrant safe, but again, that's not memory-unsafe. It just won't work properly :P
<jamesmunns-irc> e.g. if you got halfway through a grant, got an interrupt, and started another grant
<jamesmunns-irc> it would be UB
<jamesmunns-irc> you'd get two aliased muts to the same region
<jamesmunns-irc> (anything Sync generally needs to be re-entrant safe)
<cr1901> There's no mutability in my queue impl- it's all interior mutability
<cr1901> why don't I just paste the code
<jamesmunns-irc> not sure about your code
<jamesmunns-irc> only talking about bbqueue
<jamesmunns-irc> bbqueue gives you a "view" of the ringbuffer as an &mut [u8]
<cr1901> ooooooh
<jamesmunns-irc> if you had two aliasing mut slices, that would be ub, and re-entrancy would allow that to happen
<cr1901> no, my queue is not like that
<re_irc> <adamgreig> wow that did it cr1901, your messages are coming through again
<jamesmunns-irc> (cr1901 is back)
<re_irc> <adamgreig> something very peculiar is happening
jamesmunns-irc has quit [Quit: leaving]
<re_irc> <adamgreig> on my other homeserver I see 1250 members in this channel
<re_irc> <James Munns> okay now I'm over here :D
<cr1901> Can you see me now?
<re_irc> <adamgreig> but from matrix.org I only see 1072
<re_irc> <James Munns> cr1901: I can!
<re_irc> <adamgreig> it's like a bizarre netsplit...???
<cr1901> Okay very good
<cr1901> My overarching question is "can I convert your queue to 'look' like my queue without a size penalty"? Answer appears to be "no". I would rather use your queue if I can
<re_irc> <adamgreig> anyway from the matrix homeserver it thought the puppet user wasn't in the room and couldn't be kicked, but i could from the other one, idk
<re_irc> <James Munns> Yeah if you could link your API, I could take a look
<re_irc> <James Munns> but bbqueue has a real specific interface to make it "actually safe"
<re_irc> <James Munns> ohhhh
<re_irc> <James Munns> if you are only pushing/popping one element at a time
<cr1901> yes, correct
<re_irc> <James Munns> you probably want heapless::mpmc
<re_irc> <James Munns> it needs compare_exchange though
<re_irc> <James Munns> you might be able to tweak spsc to act similarly?
<cr1901> msp430 doesn't have compare exchange... which is weird, because stuff like fetch_add is gated behind "the same feature as compare exchange"
<re_irc> <James Munns> Yeah, most LLVM prims more or less can be made from a few primatives, like a swap
<re_irc> <James Munns> or really a compare exchange I think
<re_irc> <James Munns> looking at your code cr1901, I'd stick with what you have
* cr1901 nods
<cr1901> >NOTE: This module is not available on targets that do not support atomic loads, e.g. RISC-V cores w/o the A (Atomic) extension
<re_irc> <James Munns> yeah
<cr1901> Uhhh, this is a silly question but wouldn't most RISC-V cores even w/o A support a 32-bit atomic load?
<re_irc> <James Munns> you could rewrite it to rely on fetch_add
<re_irc> <James Munns> but then you'd have what you have
<re_irc> <James Munns> cr1901: IMO yes, but there's some LLVM particularities around that
<re_irc> <James Munns> (they don't have as strict of a load/store + CAS split as Rust does)
<cr1901> >Atomic CAS can only be safely emulated on single-core systems. <-- does this mean that core::sync::atomic will get code for disabling interrupts for the duration of emulating an atomic CAS?
<cr1901> I feel a bit better for being utterly confused about the state of atomics in Rust because it feels like I'm _not_ the only one
<re_irc> <James Munns> I don't think nikic idles here. I think it would be unlikely for core to add any CPU/platform specific code to it
<re_irc> <James Munns> when they talk about emulation, they are talking about crates like atomic-polyfill
<cr1901> What about taiki-e (who has been very helpful w/ msp430 lately, I must add)?
<cr1901> https://github.com/rust-lang/rust/issues/99668#issuecomment-1193310721 I wonder what is meant by this comment re: "unsound on multi-core systems because it mixes..."
<cr1901> the linked code doesn't seem to mix atomic and critical sections (it's gated by mutually exclusive cfg)
explore has joined #rust-embedded