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
richardeoin has quit [*.net *.split]
rom4ik has quit [*.net *.split]
jistr has quit [*.net *.split]
WSalmon has quit [*.net *.split]
lockna_ has quit [*.net *.split]
Rahix has quit [*.net *.split]
vollbrecht[m] has quit [*.net *.split]
sauce has quit [*.net *.split]
agg has quit [*.net *.split]
fooker has quit [*.net *.split]
sigmaris has quit [*.net *.split]
JamesMunns[m] has quit [*.net *.split]
ni has quit [*.net *.split]
andar1an[m] has quit [*.net *.split]
thejpster[m] has quit [*.net *.split]
crabbedhaloablut has quit [*.net *.split]
dne has quit [*.net *.split]
subtlename has quit [*.net *.split]
exark has quit [*.net *.split]
vanner has quit [*.net *.split]
nohit has quit [*.net *.split]
Allie has quit [*.net *.split]
dinkelhacker has quit [*.net *.split]
majors has quit [*.net *.split]
AdamHorden has quit [*.net *.split]
Socke has quit [*.net *.split]
limpkin has quit [*.net *.split]
mathu_ has quit [*.net *.split]
Rustnoob[m] has quit [*.net *.split]
TomB[m] has quit [*.net *.split]
Luc[m]1 has quit [*.net *.split]
sknebel has quit [*.net *.split]
inara has quit [*.net *.split]
ManuelHatzl[m] has quit [*.net *.split]
stgl has quit [*.net *.split]
jiande2020 has quit [*.net *.split]
pbsds3 has quit [*.net *.split]
t-moe[m] has quit [*.net *.split]
RobertJrdens[m] has quit [*.net *.split]
birdistheword99[ has quit [*.net *.split]
Foxyloxy has quit [*.net *.split]
ithinuel[m] has quit [*.net *.split]
therealprof[m] has quit [*.net *.split]
dequbed has quit [*.net *.split]
HumanG33k has quit [*.net *.split]
jr-oss has quit [*.net *.split]
wose has quit [*.net *.split]
whitequark[cis] has quit [*.net *.split]
rolodondo34[m] has quit [*.net *.split]
dav1d has quit [*.net *.split]
dirbaio[m] has quit [*.net *.split]
ryan-summers[m] has quit [*.net *.split]
cyrozap has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
dnm has quit [*.net *.split]
AlexandrosLiarok has quit [*.net *.split]
jessebraham[m] has quit [*.net *.split]
mkj[m] has quit [*.net *.split]
diondokter[m] has quit [*.net *.split]
bartmassey[m] has quit [*.net *.split]
Flix[m] has quit [*.net *.split]
hmw has quit [*.net *.split]
ello_ has quit [*.net *.split]
_catircservices1 has quit [*.net *.split]
dandels has quit [*.net *.split]
Amanieu has quit [*.net *.split]
edm has quit [*.net *.split]
Darius has quit [*.net *.split]
mightypork has quit [*.net *.split]
jasperw has quit [*.net *.split]
JamesMunns[m] has joined #rust-embedded
sigmaris has joined #rust-embedded
nohit has joined #rust-embedded
AdamHorden has joined #rust-embedded
t-moe[m] has joined #rust-embedded
RobertJrdens[m] has joined #rust-embedded
birdistheword99[ has joined #rust-embedded
ithinuel[m] has joined #rust-embedded
ni has joined #rust-embedded
TomB[m] has joined #rust-embedded
inara has joined #rust-embedded
AlexandrosLiarok has joined #rust-embedded
jessebraham[m] has joined #rust-embedded
rolodondo34[m] has joined #rust-embedded
mkj[m] has joined #rust-embedded
whitequark[cis] has joined #rust-embedded
Rustnoob[m] has joined #rust-embedded
Foxyloxy has joined #rust-embedded
diondokter[m] has joined #rust-embedded
andar1an[m] has joined #rust-embedded
Luc[m]1 has joined #rust-embedded
dav1d has joined #rust-embedded
dirbaio[m] has joined #rust-embedded
therealprof[m] has joined #rust-embedded
thejpster[m] has joined #rust-embedded
bartmassey[m] has joined #rust-embedded
ManuelHatzl[m] has joined #rust-embedded
Flix[m] has joined #rust-embedded
ryan-summers[m] has joined #rust-embedded
dne has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
hmw has joined #rust-embedded
ello_ has joined #rust-embedded
_catircservices1 has joined #rust-embedded
vollbrecht[m] has joined #rust-embedded
Rahix has joined #rust-embedded
fooker has joined #rust-embedded
agg has joined #rust-embedded
subtlename has joined #rust-embedded
stgl has joined #rust-embedded
cyrozap has joined #rust-embedded
HumanG33k has joined #rust-embedded
sauce has joined #rust-embedded
dequbed has joined #rust-embedded
dandels has joined #rust-embedded
exark has joined #rust-embedded
Amanieu has joined #rust-embedded
vanner has joined #rust-embedded
Socke has joined #rust-embedded
jiande2020 has joined #rust-embedded
edm has joined #rust-embedded
Allie has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
dnm has joined #rust-embedded
pbsds3 has joined #rust-embedded
limpkin has joined #rust-embedded
jr-oss has joined #rust-embedded
mathu_ has joined #rust-embedded
Darius has joined #rust-embedded
dinkelhacker has joined #rust-embedded
sknebel has joined #rust-embedded
wose has joined #rust-embedded
mightypork has joined #rust-embedded
majors has joined #rust-embedded
jasperw has joined #rust-embedded
Ekho has quit [Max SendQ exceeded]
m5zs7k has quit [Max SendQ exceeded]
m5zs7k has joined #rust-embedded
rom4ik has joined #rust-embedded
richardeoin has joined #rust-embedded
jistr has joined #rust-embedded
WSalmon has joined #rust-embedded
lockna_ has joined #rust-embedded
Ekho has joined #rust-embedded
sauce has quit [Server closed connection]
sauce has joined #rust-embedded
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
fooker has quit [Server closed connection]
fooker has joined #rust-embedded
agg has quit [Server closed connection]
agg has joined #rust-embedded
Rahix has quit [Server closed connection]
Rahix has joined #rust-embedded
vollbrecht[m] has quit [Server closed connection]
vollbrecht[m] has joined #rust-embedded
<RobertJrdens[m]> <RobertJrdens[m]> "How do y'all use write!()/..." <- To follow up on this, there is now: https://docs.rs/awrite/0.1.0/awrite/
<thejpster[m]> Can I get a hi five on https://github.com/rust-embedded-community/embedded-sdmmc-rs/pull/136? A PR in which I try to stop using the SPI HAL traits wrong, and make the library a bit more annoying to use because of it.
<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
<ryan-summers[m]> I've used https://github.com/quartiq/booster/blob/main/src/hardware/platform.rs#L69 in a lot of projects
<ryan-summers[m]> I wonder if something like that might actually belong in the embedded-hal?
<thejpster[m]> I tidied up some docs ahead of a 0.8.0 release: https://github.com/rust-embedded-community/embedded-sdmmc-rs/pull/138
<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]> Are there any critical-section folks or HAL team folks in the house? I'm looking at implementing the `lock-api` traits, specifically `RawMutex`, based on the `critical-section` trait, and I'm not *certain* how to correctly handle this.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/pRfArWTtAQxYOzvuXKdmqLeR>)
<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 :)
<diondokter[m]> Well, a blocking mutex like this only works if you have a critical section the entire time it's locked.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/rHeGUbxWTZvbBvXIVehmrrzj>)
DominicFischer[m has joined #rust-embedded
<DominicFischer[m> <diondokter[m]> "Well, a blocking mutex like this..." <- > <@diondokter:matrix.org> Well, a blocking mutex like this only works if you have a critical section the entire time it's locked.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HiavqDHufrGewdRxataTGhoc>)
<diondokter[m]> Sure, it works. But it's super unergonomic and in practise not better than a refcell
<diondokter[m]> At least the refcell will panic instead of deadlocking
<DominicFischer[m> For single core it's just a Sync RefCell yeah but for multicore it's better than RefCell
<JamesMunns[m]> Yeah, embassy mutexes I don't think are intended to be used with raw interrupts, but rather interrupt executors
Luc[m]1 has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> Thanks for the reviews ryan-summers . I made a 0.8.0 release at https://github.com/rust-embedded-community/embedded-sdmmc-rs/pull/137
Flix[m] has quit [Quit: Idle timeout reached: 172800s]
mkj[m] has quit [Quit: Idle timeout reached: 172800s]
rolodondo34[m] has quit [Quit: Idle timeout reached: 172800s]
TomB[m] has quit [Quit: Idle timeout reached: 172800s]
AlexandrosLiarok has quit [Quit: Idle timeout reached: 172800s]
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded
andar1an[m] has quit [Quit: Idle timeout reached: 172800s]
ithinuel[m] has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded