05:12 <re_irc> <boondocker> is there a "critical_section" implementation for RISC-V?

05:12 <re_irc> <boondocker> Getting the "undefined symbol: _critical_section_1_0_acquire" errors using "riscv" and "critical_section" crates

06:32 <re_irc> <jannic> There is one within critical_section 0.2.x, but 1.0.0 removed the implementations. They should be provided by arch specific create now. That may not be available yet.

06:32 <re_irc> But it should be easy to take the implementation from 0.2.x and use it so you can provide the implementation for 1.0.0 yourself. As long as you are on single core.

06:33 <re_irc> <jannic> * an arch specific crate

06:50 <re_irc> <jannic> Here is a pull request: https://github.com/rust-embedded/riscv/pull/110

12:21 <re_irc> <dirbaio> adamgreig: Yeah, I thought about it too

12:21 <re_irc> <dirbaio> didn't think it was worth removing it, having it doesn't hurt much (unlike the "interrupt::free" multicore unsoundness)

12:23 <re_irc> <adamgreig> yea, it's not a problem as such, but it's now not at all cortex-m specific and could be used by anyone using critical-section, I guess

12:23 <re_irc> <adamgreig> but on the other hand it really doesn't need to live in the critical-section crate

12:24 <re_irc> <dirbaio> thing is i've never been a fan of the syntax though

12:24 <re_irc> <dirbaio> so having it in c-s (which is "1.0 forever, never break it again") scares me

12:24 <re_irc> <adamgreig> yea, it feels a little bit janky

12:24 <re_irc> <adamgreig> it could be its own crate i guess.... not super enthused about the effort to benefit ratio there though

12:26 <re_irc> <dirbaio> in embassy we've been using a thing called "Forever" which does exactly the same without macros

12:26 <re_irc> https://github.com/embassy-rs/embassy/blob/master/embassy-util/src/forever.rs

12:26 <re_irc> https://github.com/embassy-rs/embassy/blob/master/examples/nrf/src/bin/multiprio.rs#L111

12:26 <re_irc> <dirbaio> more boilerplate, but at least there's no macro magic going on

12:26 <re_irc> <adamgreig> I wonder how widely used cortex-m's singleton is

12:26 <re_irc> <adamgreig> yea

12:26 <re_irc> <adamgreig> not sure if it would make sense for svd2rust PACs to use it, they need updating for critical-section either way (https://github.com/rust-embedded/svd2rust/blob/master/src/generate/device.rs#L317)

12:27 <re_irc> <adamgreig> probably doesn't really make sense

12:27 <re_irc> <dirbaio> and using TAIT you can make a macro that's just "forever!(val)", the compiler infers the type, no need to write it out at all

12:27 <re_irc> <dirbaio> https://github.com/embassy-rs/embassy/blob/master/examples/nrf/src/bin/usb_ethernet.rs#L29

12:29 <re_irc> <dirbaio> funny timing, I was splitting "Forever" to a separate crate just yesterday https://github.com/embassy-rs/static-cell

12:30 <re_irc> <dirbaio> not the macro though, TAIT is still not quite there. For example it ICEs if you do "let (a, b) = forever!((1, 2));" :D

12:30 <re_irc> <adamgreig> hah, nice

12:30 <re_irc> <adamgreig> a tricky case alright

12:31 <re_irc> <adamgreig> my fav compiler bug from very simple input's still when compiling "loop { continue; }" caused rustc to infinite loop

12:31 <re_irc> <dirbaio> lol

12:32 <re_irc> <dirbaio> so dunno, IMO the macro should go on another crate, not c-s itself yeah

12:32 <re_irc> <explodingwaffle101> dirbaio: i'm not fully awake yet- what's the diff between this and once_cell?

12:33 <re_irc> <dirbaio> static_cell gives "&'static mut" once

12:33 <re_irc> once_cell gives "&'static" many times

12:35 <re_irc> <explodingwaffle101> oooooh ok right

12:38 <re_irc> <adamgreig> makes perfect sense 🤣

12:48 <re_irc> <dirbaio> should name mine "really_only_once_cell" :P

12:48 <re_irc> <adamgreig> and give the "static_cell" name to "once_cell" :P

12:49 <re_irc> <dirbaio> 🤷😂

13:11 <re_irc> <James Munns> yomo

13:11 <re_irc> <James Munns> you only mut once

14:06 <re_irc> <jack-n> I am looking for some guidance on which repo would be the most appropriate to log it on. On Arm, if I include a core::arch::asm!("bkpt"); in my code, it halts the processor and raises a breakpoint exception, so the debugger knows what to do with it. On RISC-V (ESP32C3), if I include a core::arch::asm!("ebreak");, it sends the processor into riscv-rt's "pub fn DefaultExceptionHandler(trap_frame: &TrapFrame)". Any...

14:06 <re_irc> ... suggestions?

14:19 <re_irc> <James Munns> Probably https://github.com/rust-embedded/riscv-rt ?

14:19 <re_irc> <James Munns> Might not be _totally_ correct, but you probably have the best chance of the right people seeing it :D

14:21 <re_irc> <James Munns> jack-n: ^

14:40 <re_irc> <tiwalun> jack-n: On RISCV, you can configure the behaviour of the _ebreak_ instruction, using the _dcsr_ register. It's described in the debug spec. Maybe you have to change a setting there.

14:50 <re_irc> <mabez> tiwalun: Ah yes, that'll be it. 4.5.1 of the debug spec (0.13) probe-rs will need to set the ebreak bits for the respective modes

14:50 <re_irc> <mabez> Default at reset _doesn't_ put the chip in debug mode

14:51 <re_irc> <mabez> Probably because GCC (maybe LLVM) use ebreaks as "unreachable" markers in codegen

14:57 <re_irc> <tiwalun> We already do it in probe-rs here, for the flashloaders: https://github.com/probe-rs/probe-rs/blob/79d0a932221cf709ad9cf0abb92d95601988aa71/probe-rs/src/flashing/flasher.rs#L633

15:06 <re_irc> <ryan-summers> Anyone know what "heapless" doesn't have an unsorted linked list implementation? I want to have an ordered sequence of (large) objects that doesn't incur a ton of copying between push/pop operations

15:06 <re_irc> <ryan-summers> And/or am I missing a datastructure that does this?

15:07 <re_irc> <ryan-summers> A vec of heapless::pool::Box's does this, but I'm using this in a lib and don't know if my users can always satisfy the CAS-portability constraints of heapless::pool

15:08 <re_irc> <dirbaio> you want to insert/remove from the middle?

15:08 <re_irc> <ryan-summers> No, just at the ends

15:08 <re_irc> <ryan-summers> But need read/write throughout

15:08 <re_irc> <dirbaio> then Deque should work

15:09 <re_irc> <ryan-summers> Can you index the Deque?

15:09 <re_irc> <dirbaio> hmm, no, but there's "iter" and "as_slices"

15:09 <re_irc> <dirbaio> but indexing shouldn't be hard to add

15:09 <re_irc> <ryan-summers> That's somewhat gross :D

15:10 <re_irc> <ryan-summers> But yeah, Deque + adding index support might be the thing I want

15:10 <re_irc> <dirbaio> with a linked list indexing would be actually O(n), while deque can do it in O(1)

15:15 <re_irc> <almindor> Linked lists are rarely the thing people need.

15:15 <re_irc> <ryan-summers> Agreed. That's why I like the deque approach. Basically turns Deque into a ring-buffer

15:20 <re_irc> <ryan-summers> Actually, Deque's iteration methods look fine for my purposes. No modification necessary

15:32 <re_irc> <ryan-summers> Ugh. Deque does not work because there may be a need to reorder the list (e.g. pop in the middle). I forgot about that

15:33 <re_irc> <dirbaio> 😅

15:33 <re_irc> <ryan-summers> The MQTT spec is a beauty. The client has to maintain order, but the server (high powered PC) is free to do what it wants ;)

15:34 <re_irc> <dirbaio> maybe "Vec<atomic_pool::Box<T>>"?

15:34 <re_irc> <dirbaio> "atomic-pool" works everywhere, through "atomic-polyfill"

15:35 <re_irc> <ryan-summers> Is that not yet released? I don't see it in the 0.7.16 docs

15:35 <re_irc> <dirbaio> different crate https://github.com/embassy-rs/atomic-pool

15:36 <re_irc> <dirbaio> I wrote it because heapless's pool seemed way too complicated to me

15:36 <re_irc> <jannic> Shouldn't "heapless::pool" work for exactly the same set of architectures as "atomic-polyfill" does?

15:36 <re_irc> <ryan-summers> I think it does, but you have to enable a feature

15:39 <re_irc> <dirbaio> also "atomic-pool" has 1 bit of bookkeeping overhead per item, vs "heapless::Pool" has 32bits

15:41 <re_irc> <dirbaio> but yeah it does seem "heapless::Pool" can use "atomic-polyfill", so both should be equally portable

15:41 <re_irc> <James Munns> You could also build something on top of cordyceps::List: https://docs.rs/cordyceps/latest/cordyceps/struct.List.html

15:41 <re_irc> <James Munns> gives you a doubly linked (intrusive) list with a cursor interface

15:42 <re_irc> <dirbaio> James Munns: doesn't it need alloc?

15:42 <re_irc> <James Munns> but you'll need to BYO "storage" mechanism, e.g. how/where the nodes are stored

15:42 <re_irc> <dirbaio> ah you can bring your own box/pool

15:43 <re_irc> <James Munns> doesn't _require_ alloc, but then you need to impl some glue, yeah

15:43 <re_irc> <dirbaio> but then for this usecase you might as well use "Vec<Box<T>>" directly (with "Box" from whatever no-alloc pool)

15:43 <re_irc> <James Munns> Yeah, fair :D

15:44 <re_irc> <dirbaio> as long as O(n) is fine if it's only moving pointers, not the actual data

15:45 <re_irc> <dirbaio> oh "heapless" needs upating to "atomic-polyfill 1.0", fun

15:45 <re_irc> <ryan-summers> Yeah, I will likely have a relatively short list in general, but each element is large

15:45 <re_irc> <ryan-summers> I'm trying to figure out if heapless has the atomic-polyfill stuff on-by-default. If so, that seems fine to me

15:45 <re_irc> <ryan-summers> E.g. is it smart enough to figure out polyfill or not based on the target?

15:46 <re_irc> <explodingwaffle101> isn't that the whole point of a polyfill?

15:46 <re_irc> <ryan-summers> Yeah, but others like in shared-bus require enabling a feature IIRC

15:46 <re_irc> <dirbaio> I think you have to enable "cas" feature

15:46 <re_irc> <dirbaio> which annoys me because "atomic-polyfill" IS smart enough to automatically know when to polyfill or nt

15:46 <re_irc> <dirbaio> * not

15:47 <re_irc> <dirbaio> so heapless could inconditionally use it

15:47 <re_irc> <ryan-summers> Sounds like a PR then

15:48 <re_irc> <ryan-summers> heapless does explicitly enable "cas" and thus "atomic-polyfill" by default

15:48 <re_irc> <dirbaio> was already discussed https://github.com/japaric/heapless/pull/220

15:49 <re_irc> <dirbaio> reason was "it pulls cortex-m stuff in non-cortex-m targets"

15:49 <re_irc> <dirbaio> but that's fixed with "critical-section 1.0"! :D

15:51 <re_irc> <dirbaio> so perhaps worth a 2nd try

16:04 <re_irc> <dirbaio> ah, but there's heapless structs that use atomic load/store only

16:09 <re_irc> <dirbaio> which will be a perf regression with the current "atomic-polyfill", because it polyfills load/store too if there's no native CAS

16:09 <re_irc> <dirbaio> +with a CS

16:09 <re_irc> <dirbaio> (early "atomic-polyfill" versions allowed mixing native load/store + polyfilled CAS, but that's unsound)

16:10 <re_irc> <dirbaio> There were some discussions about adding "load_store_only::AtomicXX" variants to "atomic-polyfill"

16:11 <re_irc> <dirbaio> which would still lower to native load/store, on targets with native load/store but no CAS

16:11 <re_irc> <dirbaio> 🤔

16:17 <re_irc> <chrysn (@chrysn:matrix.org)> dirbaio, I'm just giving the nrf-softdevice a test run. I'm guessing at a few steps in the middle (not having used probe-run before). Is there any kind of intro text / article that is more detailed than the nrf-softdevice README?

16:18 <re_irc> <chrysn (@chrysn:matrix.org)> No problem if there isn't any, but I'd prefer not to learn things the hard(er) way and later see that it was all in the intro.

16:18 <re_irc> <dirbaio> no docs other than what's in the repo, no

16:19 <re_irc> <dirbaio> if you're stuck on something feel free to ask for help in #embassy-rs:matrix.org (https://matrix.to/#/#embassy-rs:matrix.org)

16:19 <re_irc> <chrysn (@chrysn:matrix.org)> OK, thanks!

19:35 <bjc> has anyone here managed to get usb working on a gd32vf103c-start board? i've been tearing my hair out for weeks and am about to give up

19:36 <bjc> at this point i assume i have to set some jumpers somehow, but there doesn't even appear to be documentation in chinese for them

19:39 <bjc> i'm currently trying with the synopsys-usb-otg crate, but i've alse tried about every enumeration of doing it by hand that i can think of. i can get as far as getting the reset interrupt, but nothing past that; like the host doesn't even see it. maybe there's a gpio pull up i have to configure like on the gd32f303 series?

21:06 <agg> bjc: sorry, the matrix->irc bridge is currently acting up and your messages don't seem to have made it through to matrix

21:09 <bjc> thanks for letting me know. i'll try again later