<ryan-summers[m]>
I wonder if you could take 2 SpiDevices, one with a dummy CS and one without, to manage the dummy clocks
<ryan-summers[m]>
But eh, seems like forcing stuff on the user that might not be necessary.
<ryan-summers[m]>
In general, there's a lot of protocols that require you to "prime" the bus. I2C is a great example that many people don't take into account. If you unexpectedly reset during an I2C transaction, the bus can be in a hung state and you need to manually clear it by flagging a number of I2C clock cycles
<thejpster[m]>
I've tried to make sure my docs start with a short sentance, and then a blank line. This makes subsequent lines in the comment not appear in the top-level summary. Reminds me of javadoc tbh.
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
(in this case, lock_a and lock_b are mutexes covering different data, they both just happen to be using a critical section as the backing raw mutex implementation)
diondokter[m] has joined #rust-embedded
<diondokter[m]>
There's probably a reason why Embassy doesn't do it this way
<JamesMunns[m]>
This wouldn't happen if you were using nested ::with statements, because everything gets dropped in LIFO/stack order. But if I'm making my own mutex type ON TOP of critical section, e.g. raw calls to acquire() and release(), then that gets spicy
<diondokter[m]>
Yeah, this doesn't look right
<diondokter[m]>
Maybe try what the async mutex of embassy does?
<diondokter[m]>
It uses critical section only to set a flag in the mutex
<diondokter[m]>
Flag already taken? Then the mutex won't unlock
<diondokter[m]>
But that doesn't really play nice with single-threaded
<JamesMunns[m]>
ahhh, embassy has a slightly different API, it does the blocking mutex stuff in a closure
<diondokter[m]>
Yep
<JamesMunns[m]>
that solves the stacking problem. But might be a deal breaker for trying to be compatible with the lock-api crate, which is a bummer
<thejpster[m]>
it looks like you have two values (of type Mutex) describing one hardware resource (the NVIC 'interrupts disabled' flag).
<thejpster[m]>
Which just sounds like trouble. They need to share some ref-coun value, so the primask is only reset when it gets back to zeor.
<thejpster[m]>
s/coun/count/, s/zeor/zero/
<diondokter[m]>
I'm not sure if a mutex like this is practical without async or multiple threads
<diondokter[m]>
s/multiple/real/
<JamesMunns[m]>
yeah, the rub here is that the mutex is usually "stacked", at least for critical sections:
<JamesMunns[m]>
* There's the RAW mutex around the "is taken" flag of the outer mutex: so a short CS just to safely check "is taken"
<JamesMunns[m]>
* There's the outer mutex, that gives one-at-a-time access to the guarded resource
<JamesMunns[m]>
the RAW mutex is blocking, the outer mutex can be async or blocking
<JamesMunns[m]>
the goal for maitake-sync was to use lock-api to be generic over RawMutex kinds, sort of like how embassy has its own RawMutex traits
<JamesMunns[m]>
(and eventually, maybe making embassy-sync generic over the same lock-api traits)
<JamesMunns[m]>
but now I'm not sure if there's an impedence mismatch with that.
<JamesMunns[m]>
I'll have a think about it, open to other thoughts :)