<Ralph[m]>
CI fails because of this (and i just double-checked and noticed that my IDE also doesn't resolve the link but fails to offer me a way which works) - i'm 99% sure that i've previously linked in exactly this way and checking the rustdoc docs didn't clear this up
<Ralph[m]>
(i think i should know the answer, it seems like something super basic and i'm not new to rust anymore 🙈)
AshconMohseninia has quit [Quit: Idle timeout reached: 172800s]
davidmpye[m] has quit [Quit: Idle timeout reached: 172800s]
realroot[m]1 has quit [Quit: Idle timeout reached: 172800s]
DavidBrown[m] has joined #rust-embedded
<DavidBrown[m]>
I have an interesting dilemma. In Zephyr, the spinlock_t locks cannot be nested. It is assumed to nest, they need to be separate locks. But, the critical_section crate only offers an 'acquire' and 'release' function, which doesn't give me a place to store this. I've been using a single global static, but it turns out that breaks with SMP targets, because critical sections are frequently nested in Rust. Any thoughts on how to
<DavidBrown[m]>
implement this.
<Ralph[m]>
<DominicFischer[m> "RustRover, in my experience..." <- yeah, the experience with `esp-hal` in RustRover isn't that great (most likely the fault of RR, not esp-hal!) - for some reason I can't toggle the features in `Cargo.toml` the checkboxes are greyed out instead of editable as in other projects), thus I couldn't even select esp32 and didn't have proper support for it 🙁
<DavidBrown[m]>
The good news is that I at least understand why I'm seeing issues with critical sections on SMP. The bad news is that I'm not actually sure how to provide critical sections on Zephyr.
<DominicFischer[m>
<DavidBrown[m]> "I have an interesting dilemma..." <- What's wrong with the single global static?
<DavidBrown[m]>
DominicFischer[m: It deadlocks if you nest critical sections.
<DavidBrown[m]>
Zephyr spinlocks cannot nest the same spinlock. You can nest different ones.
<DominicFischer[m>
Right, but it doesn't deadlock single core chips?
<DominicFischer[m>
Oh, or are you in a position where you can't disable interrupts?
<DavidBrown[m]>
If you enable CONFIG_ASSERT on Zephyr, it hits an assertion failure that ensures you aren't nesting spinlocks.
<DavidBrown[m]>
The issue is with the spinlock implementation.
<DominicFischer[m>
Okay, I think I misunderstood your message. I thought you had a workaround for single core chips, which doesn't appear to be the case.
<DavidBrown[m]>
I'm thinking I might have to make my own implementation. Without SMP, I can use irq locking. With SMP, I can use an atomic. This has the same issue that Zephyr currently does that SMP on targets without atomic instructions won't build, but that is expected.
<DavidBrown[m]>
It "works" on single-core, but only if you have assertions off. It just happens to work, rather than actually following the spec for Zephyr's spinlocks.
<DominicFischer[m>
Right, got it. Yes, you'll have to roll your own.
<DominicFischer[m>
* your own implementation.
<DominicFischer[m>
I tend to frown on critical_section usage on SMP anyway as it's not granular enough in most cases. People just generally put up with the extra contention without a care.
<DavidBrown[m]>
Is there a portable way to do the memory barriers needed, though?
<DominicFischer[m>
fence and compiler_fence?
<DavidBrown[m]>
That looks like it might be the case. Oddly, I think that would make my implementation more correct than Zephyr's.
<Ralph[m]>
spikespaz[m]: AFAIK the general consensus for this is that - for the time being - you don't use a workspace in this case (or maybe use one per platform? haven't tried that yet). so you just have several crates in a folder but no workspace defined
<spikespaz[m]>
Ralph[m]: Thus, no shared compilation database. I need that.
<spikespaz[m]>
So, the next best solution to explore is two workspaces?
<spikespaz[m]>
AdinAck
pcs38 has quit [Quit: leaving]
<i509vcb[m]>
Is there some way to get rustc to dump the final linker script after everything from other crates has been added?
pcs38 has joined #rust-embedded
korken89[m] has joined #rust-embedded
<korken89[m]>
<i509vcb[m]> "Is there some way to get rustc..." <- search `target/` for `link.x`, it should be there
<korken89[m]>
e.g. target/thumbv8m.main-none-eabi/release/build/cortex-m-rt-4b1810fad4e47ed6/out/link.x
kenny has quit [Ping timeout: 244 seconds]
richardeoin has joined #rust-embedded
kenny has joined #rust-embedded
slyons[m] has joined #rust-embedded
<slyons[m]>
<i509vcb[m]> "Apparently I am getting an..." <- So from their TRM on RIS and MIS is that RIS is “regardless of masking”. Is that interrupt being vectored?
pcs38 has quit [Quit: leaving]
<i509vcb[m]>
<slyons[m]> "So from their TRM on RIS and MIS..." <- So MIS = RIS AND IMASK