<gussius[m]>
Hi All, I am trying to twist my brain around type-level metaprogramming in rust. I have seen bradleyharden's work on atsamd-hal, and would like to understand it more. Anyone know of any learning resources? I think I need to start small to understand the concepts then build on them. Jumping into atsamd-hal crate is a bit too much for my poor brain at this stage.
<gussius[m]>
Yes. I guess I need to just study them.. a lot more. And hopefully it clicks.
<gussius[m]>
It is a good guide. But I don't think my knowledge base is quite at the level yet to easily consume such a guide.
notgull has quit [Ping timeout: 246 seconds]
notgull has joined #rust-embedded
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
Matt[m] has joined #rust-embedded
<Matt[m]>
<dngrsspookyvisio> "I was also gonna suggest link..." <- bonjour seems like a nice way to do things. win11 even supports it these days?
<M9names[m]>
Windows 10, too. I was very glad when windows started supplying their own mdns service so I didn't need to install bonjour
Rahix_ has joined #rust-embedded
duderonomy_ has joined #rust-embedded
duderonomy has quit [*.net *.split]
Rahix has quit [*.net *.split]
<dngrsspookyvisio>
Oh nice
IlPalazzo-ojiisa has joined #rust-embedded
tr09[m] has quit [Quit: Idle timeout reached: 172800s]
<diondokter[m]>
So one or two weeks ago I read here (or in the embassy chat) that some people wanted to work on radio abstractions in Rust. Does anybody know who those people are? I don't remember. Has anything started with that?
<explodingwaffle1>
there's been a lot of chatter in #public-lora-wan-rs:matrix.org if that's what you're talking about. not my area though
<adamgreig[m]>
I feel like we've discussed this before and concluded it was fine
meptl[m] has quit [Quit: Idle timeout reached: 172800s]
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
eldruin: i think we again need a github release for embedded-hal-1.0.0-rc.1 correct?
burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has joined #rust-embedded
<jannic[m]>
Yes, I'm also quite sure there was such a discussion, either here or in some github ticket.
<jannic[m]>
However I can't remember the reasoning. Was it just like "it's incredibly unlikely to have an interrupt handler that disables interrupts and leaves them disabled on return"?
<jannic[m]>
* > I feel like we've discussed this before and concluded it was fine
<jannic[m]>
Yes, I'm also quite sure there was such a discussion, either here or in some github ticket.
<jannic[m]>
However I can't remember the reasoning. Was it just like "it's incredibly unlikely to have an interrupt handler that disables interrupts and leaves them disabled on return"?
eZioPan[m] has quit [Quit: Idle timeout reached: 172800s]
corecode[m] has quit [Quit: Idle timeout reached: 172800s]
NishanthMenon has quit [Server closed connection]
NishanthMenon has joined #rust-embedded
Noah[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
yeah the "we assume interrupts leave enable/disable state unchanged" thing was discussed and we concluded it was OK
<dirbaio[m]>
(it should be doc'd though)
<dirbaio[m]>
but that's orthogonal to what I think is the main topic of the issue, which is it seems interrupt enable needs DMB/DSB
IlPalazzo-ojiisa has quit [Remote host closed the connection]
Jonas[m]1 has quit [Quit: Idle timeout reached: 172800s]
adinack[m] has quit [Quit: Idle timeout reached: 172800s]
ilpalazzo-ojiis4 has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
Only if you need a pending interrupt to run before the instruction immediately following the cpsie though?
<adamgreig[m]>
Like it's not generally a problem for an instruction or two to run after cpsie before a pending interrupt, it can't cause a critical section violation or anything
<adamgreig[m]>
I think only isb too
<dirbaio[m]>
ahh
<dirbaio[m]>
so
<dirbaio[m]>
what we guarantee now is "exit CS" happens-before "interrupt handler runs"
<dirbaio[m]>
adding the DSB/ISB would also guarantee "interrupt handler runs" happens-before "exit CS returns"
<dirbaio[m]>
for an interrupt that was pended while inside the CS
nadja has quit [Server closed connection]
<dirbaio[m]>
?
nadja has joined #rust-embedded
<adamgreig[m]>
Only isb is relevant, but yea, any pended interrupt would run immediately after the cpsie if it's followed by isb
<adamgreig[m]>
(which is already the case in all cortex-m anyway)
<dirbaio[m]>
ah then it's less bad than I thought
<adamgreig[m]>
Otherwise it can be up to an instruction or two after cpsie
<dirbaio[m]>
I had understood the issue was saying that the 1st guarantee we're giving is broken
<adamgreig[m]>
I think it's not bad at all and we went over it last time someone read that technical note but I might be misremembering
<dirbaio[m]>
but if it's not the case, I wouldn't change anything
<dirbaio[m]>
current code doesn't rely on the 2nd guarantee, only on the 1st
<adamgreig[m]>
Incidentally if the instruction after cpsie is cpsid then a pending interrupt will definitely run, on cortex m
<dirbaio[m]>
like
<dirbaio[m]>
if you think of CSs like mutexes:
<dirbaio[m]>
the mutexes only guarantee no two threads hold the mutex at the same time
<dirbaio[m]>
they don't guarantee that when you release a mutex, the other thread that was waiting "immediately" grabs it
<dirbaio[m]>
it's guaranteed to grab it "after", but not "immediately after"
<adamgreig[m]>
Right. That's never a property we've talked about or anyone's needed
<dirbaio[m]>
currently in embedded rust if you want to read state that was written by the ISR, you have to take another CS
<dirbaio[m]>
and that does synchronize stuff
<dirbaio[m]>
so this only seems relevant for using unsafe to read state written by the ISR without taking a second CS
<adamgreig[m]>
like, if you pend an isr during a cs and then finish the cs and immediately want to read the results of the isr execution?
<dirbaio[m]>
yeah?
<dirbaio[m]>
which seems a very cursed thing to do
<dirbaio[m]>
so if that's the only use case we're "sacrificing" by not having ISB then IMO it's fine
<dirbaio[m]>
are there more though? :D
<adamgreig[m]>
hope not :D
duderonomy_ has quit [Ping timeout: 258 seconds]
<adamgreig[m]>
dirbaio: I guess you could `cs::with(|_| pend_interrupt_that_writes_an_atomic); let x = SHARED_ATOMIC.load();`