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
gussius[m] has joined #rust-embedded
<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.
notgull has quit [Ping timeout: 246 seconds]
notgull has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
M9names[m] has joined #rust-embedded
<M9names[m]> Have you checked the docs?
<JamesMunns[m]> woah, I hadn't seen that before, that's a really nice guide
<M9names[m]> Starting small is a good idea though. Helps build up your intuition
<gussius[m]> M9names[m]: > <@9names:matrix.org> Have you checked the docs?
<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
<diondokter[m]> Thanks! I'll check that out
<diondokter[m]> Didn't know that room existed :D
<dirbaio[m]> <diondokter[m]> "So one or two weeks ago I read..." <- maybe this? https://github.com/embassy-rs/embassy/issues/1800
<diondokter[m]> dirbaio[m]: Ah that might be it, thanks!
<JamesMunns[m]> Just a heads up to any of the German folks out there, I'll be talking about [MnemOS](https://mnemos.dev/) in Berlin and Frankfurt this month! https://summit.riot-os.org/2023/blog/speakers/james-munns/ and https://www.meetup.com/berlin-firmware-embedded-systems-meetup/
nex8192 has left #rust-embedded [Error from remote client]
jessebraham[m] has quit [Quit: Idle timeout reached: 172800s]
BenoitLIETAER[m] has quit [Quit: Idle timeout reached: 172800s]
nex8192 has joined #rust-embedded
marmrt[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> https://github.com/rust-embedded/cortex-m/issues/484 ... uhhhh ..... oh no?
<JamesMunns[m]> Oh that's fun
GenTooMan has quit [Ping timeout: 258 seconds]
GenTooMan has joined #rust-embedded
<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();`
dne has quit [Remote host closed the connection]
crabbedhaloablut has quit []