dc_740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
dc740 has quit [Remote host closed the connection]
Socke has quit [Ping timeout: 252 seconds]
Socke has joined #rust-embedded
conplan has joined #rust-embedded
richardeoin has quit [Ping timeout: 252 seconds]
richardeoin has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> Misc note, I reserved/squatted "rustembedded" on cohost. As always, if anyone else from the WG/Resources team wants to be added as a page admin, just ping me:
thomas25 has quit [Read error: Software caused connection abort]
thomas25 has joined #rust-embedded
<re_irc>
< (@dkhayes117:matrix.org)> : Have you thought of applying for a rust foundation grant?
<re_irc>
< (@jamesmunns:beeper.com)> > Awards made to individuals and groups for discrete pieces of work in the range of $2,500 to $15,000.
<re_irc>
< (@jamesmunns:beeper.com)> Speaking honestly, that level of support is probably only enough for a "feasibility study", or basically, scoping out how what needs to be done, or how much more money is needed
<re_irc>
< (@adamgreig:matrix.org)> : ooh, good idea! could you add me?
<re_irc>
< (@jamesmunns:beeper.com)> Yeah! I'll wait to see if anyone else acks, since the "adding" process is a manual email
<re_irc>
< (@jamesmunns:beeper.com)> Actually I'll do it now, because otherwise I will forget. I hope they forgive me if more people ack :D
<re_irc>
< (@adamgreig:matrix.org)> they don't like making their life easy huh :D
<re_irc>
< (@jamesmunns:beeper.com)> > pages can have multiple editors, but we haven't built a UI for you to manage the editorship of a page yet. if you want to co-edit this page with collaborators, please e-mail us at support@cohost.org with their username and the name of the page, and we'll get everything sorted out for you.
<re_irc>
< (@adamgreig:matrix.org)> I guess they are a little busy approving twitter emigrants as fast as possible right now
<re_irc>
< (@jamesmunns:beeper.com)> Sent a request (and CC'd you!)
<re_irc>
< (@adamgreig:matrix.org)> thanks :)
conplan has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 248 seconds]
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #rust-embedded
starblue has joined #rust-embedded
Andy_Flatline has joined #rust-embedded
Andy_Flatline has quit [Quit: Client closed]
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
causal has quit [Quit: WeeChat 3.7.1]
explore has joined #rust-embedded
stephe has quit [Ping timeout: 268 seconds]
stephe has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 255 seconds]
cr1901 has joined #rust-embedded
cr1901_ has quit [Read error: Connection reset by peer]
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
<re_irc>
< (@diondokter:matrix.org)> : I think it used to be atomic, but now that name has been turned into a lie :P
<re_irc>
< (@korken89:matrix.org)> Yeah it does some optimization so it can't be used externally as I understand it
<re_irc>
< (@korken89:matrix.org)> Ah no, that was something different
<re_irc>
< (@diondokter:matrix.org)> Yeah, there used to be two variants. One for normal wakers and one specialized for Embassy's waker. But now there is just one for the normal waker
<re_irc>
< (@diondokter:matrix.org)> I don't know why that was changed now
<re_irc>
< (@diondokter:matrix.org)> You can use it though. This is part of the now on crates.io published "embassy-sync" crate
<re_irc>
< (@korken89:matrix.org)> Which I think is fine in embedded as it's only a 12b memcpy
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
<re_irc>
< (@dirbaio:matrix.org)> 8b :)
<re_irc>
< (@korken89:matrix.org)> Even better :D
<re_irc>
< (@korken89:matrix.org)> It's a critical section I can live with
<re_irc>
< (@dirbaio:matrix.org)> the reason embassy removed the "optimized" 1-word wakers is it didn't make much of a difference in real world projects
<re_irc>
< (@dirbaio:matrix.org)> very tiny code size saving
<re_irc>
< (@dirbaio:matrix.org)> +/ RAM
<re_irc>
< (@dirbaio:matrix.org)> because even if you "optimize" the waker when storing it in a WakerRegistration, it's still "unoptimized" when it's within the "core::task::Context"
<re_irc>
< (@dirbaio:matrix.org)> i'd guess it would make a difference if it was optimized all the way through, but that'd require forking libcore :D
<re_irc>
< (@dirbaio:matrix.org)> (optimized wakers did have quite a bit of impact in interrupt latency btw, because no virtual calls)
<re_irc>
< (@korken89:matrix.org)> Hehe
<re_irc>
< (@chemicstry:matrix.org)> virtual calls is the usage of "dyn" right? How bad is it actually? There is a lot of fear for it, but isn't it just a few extra instruction for the lookup?
<re_irc>
< (@chemicstry:matrix.org)> i.e. it will be dwarfed by any other activity unless you call it in some loop, which is not the case here
<re_irc>
< (@korken89:matrix.org)> Indeed, there are a few indirections that happens, and ever indirection is maybe 5-10 clocks
<re_irc>
< (@korken89:matrix.org)> So all-in-all, no big difference
<re_irc>
< (@dirbaio:matrix.org)> in practice it's quite the perf hit because it prevents inlining
<re_irc>
< (@dirbaio:matrix.org)> which prevents further optimizations
Foxyloxy has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
< (@korken89:matrix.org)> Btw, I've been playing around a bit with an interrupt registration scheme that is more towards your trait based one. But I also wanted to natively support adding wakers somehow but without a cost if not being used, so not everyone needs to reinvent that wheel again.
<re_irc>
< (@korken89:matrix.org)> More or less the HAL implementor can set the associated const "NUM_WAKERS" and the rest will happen automagically
<re_irc>
< (@korken89:matrix.org)> 100% untested btw, only checked that it compiles
<re_irc>
< (@korken89:matrix.org)> I don't like that I was forced to use slices though, but using an associated const to set the size of arrays was not allowed...
<re_irc>
< (@dirbaio:matrix.org)> why pass the wakers through the interrupt registration stuff? vs just letting the HAL declare its own statics?
<re_irc>
< (@korken89:matrix.org)> Design choice
<re_irc>
< (@korken89:matrix.org)> So each HAL implementer does not need to understand how to do it, unless they really want to and then they can do it their own way
<re_irc>
< (@korken89:matrix.org)> I noticed that quite quickly when testing writing for a few HALs I was creating the same code everywhere
<re_irc>
< (@korken89:matrix.org)> Plus if you do it this way you don't pay for the (small) memory footprint unless you register it
<re_irc>
< (@korken89:matrix.org)> Not something I'd see as important though
<re_irc>
< (@dirbaio:matrix.org)> : statics are optimized away if unused
<re_irc>
< (@korken89:matrix.org)> Then scratch that
<re_irc>
< (@korken89:matrix.org)> Not sure it's better or worse to "just copy what I did before"
<re_irc>
< (@korken89:matrix.org)> But this does exemplify an automatic way
<re_irc>
< (@dirbaio:matrix.org)> how are you doing wakers in HALs?
<re_irc>
< (@korken89:matrix.org)> Giving them a "static" for waker handling and then sharing that reference around
<re_irc>
< (@dirbaio:matrix.org)> in my experience it's been just "declare the static, then use it"
<re_irc>
< (@dirbaio:matrix.org)> just 1 line of code
<re_irc>
< (@korken89:matrix.org)> Yeah
<re_irc>
< (@dirbaio:matrix.org)> plus you often want to share state beyond just the wakers, so you still have to do it on your own because the interrupt macros would help you just for the wakers
<re_irc>
< (@korken89:matrix.org)> Indeed
<re_irc>
< (@korken89:matrix.org)> Maybe copy-paste is the way to do
<re_irc>
< (@korken89:matrix.org)> * go
<re_irc>
< (@korken89:matrix.org)> Probably good enough
<re_irc>
< (@korken89:matrix.org)> And not that much to understand about wakers and their handling
<re_irc>
< (@korken89:matrix.org)> The waker registration stuff is quite self contained
<re_irc>
< (@korken89:matrix.org)> I think I'll sort this experiment into the "overdesigned" bin
<re_irc>
< (@korken89:matrix.org)> I was looking at our old convo, you had some issue with this approach - could you expand on it?
<re_irc>
< (@dirbaio:matrix.org)> I don't remember lol
<re_irc>
< (@korken89:matrix.org)> Haha
<re_irc>
< (@dirbaio:matrix.org)> one issue I see is you're not enforcing at compile-time that the user has registered the right interrupt
<re_irc>
< (@korken89:matrix.org)> Well, it seems both the "run time registration" and "compile time registration" works
<re_irc>
< (@korken89:matrix.org)> : It's part of the HAL
<re_irc>
< (@korken89:matrix.org)> Or, it is a "const_assert" there that I did not finish hacking out
<re_irc>
< (@korken89:matrix.org)> Could also be part of "InterruptRegistration" trait and checked by the macro codegen
<re_irc>
< (@dirbaio:matrix.org)> oh huh
<re_irc>
< (@korken89:matrix.org)> Which would maybe make more senes
<re_irc>
< (@korken89:matrix.org)> * sense
<re_irc>
< (@korken89:matrix.org)> So the HAL implementer does not need to check it
<re_irc>
< (@dirbaio:matrix.org)> can you do a const_assert like that?
<re_irc>
< (@korken89:matrix.org)> Sure, we do it a lot in RTIC
<re_irc>
< (@dirbaio:matrix.org)> 🤔
<re_irc>
< (@korken89:matrix.org)> Though it expands to a struct that has a const and you assert in the const
<re_irc>
< (@dirbaio:matrix.org)> the solution I had in mind is to codegen a _type_ for each interrupt, then "new" can do "where Handle: InterruptHandle<Spi0>"
<re_irc>
< (@korken89:matrix.org)> Which forces the compiler to check the panic at comiple time
<re_irc>
< (@dirbaio:matrix.org)> but the annoying thing is svd2rust doesn't do that
<re_irc>
< (@korken89:matrix.org)> I think I can turn this inside out so the codegen does the check
<re_irc>
< (@dirbaio:matrix.org)> the const_assert idea is interesting, it means it'd work with "standard" PACs without extra codgen
<re_irc>
< (@dirbaio:matrix.org)> one minor downside is rustdoc no longer shows which irq "new" wants
<re_irc>
< (@korken89:matrix.org)> There, added and tested working
<re_irc>
< (@korken89:matrix.org)> Just as an example
<re_irc>
< (@dirbaio:matrix.org)> you have to somehow check it in "new"
<re_irc>
with that code you can still register Spi1 irq to the Spi1 driver (which will pass the check in the macro) and then give that handle to Spi0::new
<re_irc>
< (@dirbaio:matrix.org)> - single irq shared between multiple drivers
<re_irc>
- single driver that needs single irq or multiple irqs depending on which chip of the family it is
<re_irc>
- single driver that needs multiple irqs
<re_irc>
< (@dirbaio:matrix.org)> (yes stm32 has all these)
<re_irc>
< (@korken89:matrix.org)> If one wants to check it in new it's the old code
<re_irc>
< (@korken89:matrix.org)> - single irq shared between multiple drivers
<re_irc>
< (@korken89:matrix.org)> This should not be a problem for the registration, the HAL implementor will need to write a driver that does the multiple things
<re_irc>
< (@dirbaio:matrix.org)> it's not "multiple things", it's completely unrelated things, like USART4 + I2C0
<re_irc>
< (@dirbaio:matrix.org)> you don't want a "Usart4I2c0Driver" in the HAL
<re_irc>
< (@korken89:matrix.org)> Ah no, what I mean is for something like that you can go through a struct which takes both and implements the interrupt trait that calls both's handlers
<re_irc>
< (@dirbaio:matrix.org)> you also want to be able to use Usart4 without pulling in code for i2c0, that wouldn't do it
<re_irc>
< (@korken89:matrix.org)> Exactly, so then this would not do so
<re_irc>
< (@korken89:matrix.org)> Only if you use the "merger" struct/tuple would the code be pulled in
<re_irc>
< (@dirbaio:matrix.org)> STM32G0C1VE has "USART3_4_5_6_LPUART1" interrupt. 5 peripherals! :D
<re_irc>
< (@dirbaio:matrix.org)> You generate 32 combinations of these "merger" structs?
<re_irc>
< (@korken89:matrix.org)> Or a defined sequence
<re_irc>
< (@dirbaio:matrix.org)> or also "DMA1_Ch4_7_DMA2_Ch1_5_DMAMUX1_OVR". 10 peripherals (if you count each DMA channel separately)
<re_irc>
< (@korken89:matrix.org)> You must also not use the registration to solve it
<re_irc>
< (@korken89:matrix.org)> You can "register" internally in your HAL
<re_irc>
< (@korken89:matrix.org)> So if a driver registers to the interrupt handler, it will be called
<re_irc>
< (@korken89:matrix.org)> A bit of overhead though, but only a single indirection
<re_irc>
< (@dirbaio:matrix.org)> for DMA maybe yes
<re_irc>
< (@dirbaio:matrix.org)> for "USART3_4_5_6_LPUART1" ideally you want the "normal" machinery to handle it
<re_irc>
< (@dirbaio:matrix.org)> because in many other chips the usart doesn't share irqs like that
<re_irc>
< (@dirbaio:matrix.org)> you don't want the usart driver to "care" which chip it is
<re_irc>
< (@dirbaio:matrix.org)> when I looked at this thing
<re_irc>
< (@dirbaio:matrix.org)> my conclusion was
<re_irc>
< (@dirbaio:matrix.org)> you can't get away without introducing some concept of "interrupt functions"
<re_irc>
< (@dirbaio:matrix.org)> for stm32 at least
<re_irc>
< (@dirbaio:matrix.org)> nrf and rp2040 are cleaner, in these your "1 driver = 1 interrupt" model works
<re_irc>
< (@dirbaio:matrix.org)> (I think atsamd also does this cursed stm32-like interrupt sharing)
<re_irc>
< (@korken89:matrix.org)> Hmm, not quite sure I see the issue. As the HAL implementer knows which share an interrupt, adding a mechanism to call multiple underlying handlers does not sound like an issue?
<re_irc>
< (@korken89:matrix.org)> Because else you force the knowledge on the user
<re_irc>
< (@korken89:matrix.org)> How most likely knows even less about how ISRs are shared
<re_irc>
< (@korken89:matrix.org)> * Who
<re_irc>
< (@dirbaio:matrix.org)> the user has to know which drivers needs which interrupts, there's no way around that
<re_irc>
< (@korken89:matrix.org)> What I mean is, either the user or the HAL implementer need to do the connector - so if I could choose I'd lay that on the HAL implemented that does have the knowledge
<re_irc>
< (@korken89:matrix.org)> * connection
<re_irc>
< (@korken89:matrix.org)> * implementor
<re_irc>
< (@korken89:matrix.org)> What I mean is, either the user or the HAL implementer need to do the connection - so if I could choose I'd lay that on the HAL implementor that does have the knowledge
<re_irc>
< (@dirbaio:matrix.org)> No, there's a 3rd way, the "register_interrupt!" machinery should do the connector
<re_irc>
< (@dirbaio:matrix.org)> * connection
<re_irc>
< (@korken89:matrix.org)> Hmm, how?
<re_irc>
< (@korken89:matrix.org)> It can't intrusively check the HAL so there must be some other mechanism then
<re_irc>
< (@korken89:matrix.org)> Or linker shenanigans
<re_irc>
< (@dirbaio:matrix.org)> introduce the concept of "interrupt function"
<re_irc>
< (@dirbaio:matrix.org)> USART6 driver does "fn new<H>(..) where H: Handle<irq_functions::USART6>"
<re_irc>
< (@korken89:matrix.org)> Ah, so you have the macro generate a type that implements all the different target functions as part of multiple trait signatures
<re_irc>
impl InterruptFunction<USART5> for USART3_4_5_6_LPUART1 {}
<re_irc>
< (@dirbaio:matrix.org)> HAL has some interrupt -> interrupt function mapping, like
<re_irc>
impl InterruptFunction<USART4> for USART3_4_5_6_LPUART1 {}
<re_irc>
impl InterruptFunction<USART3> for USART3_4_5_6_LPUART1 {}
<re_irc>
< (@korken89:matrix.org)> And let the trait system check
<re_irc>
< (@dirbaio:matrix.org)> +....
<re_irc>
< (@dirbaio:matrix.org)> user does "register_interrupt!(USART3_4_5_6_LPUART1: USART4, USART6);".
<re_irc>
this checks that irq indeed has these functions
<re_irc>
< (@dirbaio:matrix.org)> and "new" checks the function it cares about has been indeed registered
<re_irc>
< (@dirbaio:matrix.org)> so
<re_irc>
< (@dirbaio:matrix.org)> the driver doesn't care whether there's interrupt sharing going on or not
<re_irc>
< (@dirbaio:matrix.org)> the only thing that has to change is the function impls
<re_irc>
< (@korken89:matrix.org)> Hmm, I need to play around a bit with that to build my understanding what side effects it has on macro/HAL/user
<re_irc>
< (@dirbaio:matrix.org)> on a chip without sharing it'll be "impl InterruptFunction<USART6> for USART6 {}"
<re_irc>
but the driver can stay unchanged
<re_irc>
< (@korken89:matrix.org)> Makes sense
<re_irc>
< (@dirbaio:matrix.org)> the bad side effect is this extra "indirection" in the trait system makes stuff harder to understand
<re_irc>
< (@dirbaio:matrix.org)> but for stm32 you NEED it :S
<re_irc>
< (@korken89:matrix.org)> Yeah, it's not clear to me how the connection happens
<re_irc>
< (@dirbaio:matrix.org)> my plan was to make 2 versions of this. one with for stm32, one without for nrf, rp2040
<re_irc>
< (@dirbaio:matrix.org)> this is why I'm not 100% convinced of the idea of a "cortex-m-interrupt" lib that all HALs can share
<re_irc>
< (@dirbaio:matrix.org)> if you make "cortex-m-interrupt" too flexible with "interrupt functions" you hurt the usability of HALs for simpler chips like nrf, rp2040
<re_irc>
< (@dirbaio:matrix.org)> if you don't then you can't use it for stm32
<re_irc>
< (@korken89:matrix.org)> I'll play around a bit with that concept so I get a feel for it
wose has quit [*.net *.split]
<re_irc>
< (@chemicstry:matrix.org)> talking from embassy perspective, couldn't you just have something like "struct MultiInterrupt", which takes the original hardware interrupt and gives out multiple handlers implementing the same "Interrupt" trait to be used in drivers? Internally it would just iterate through all issued handlers
<re_irc>
< (@dirbaio:matrix.org)> yeah, that'd need some indirection at runtime though (?)
<re_irc>
< (@dirbaio:matrix.org)> the idea is "register_interrupt!(USART3_4_5_6_LPUART1: USART4, USART6);" would generate
<re_irc>
#[interrupt] fn USART3_4_5_6_LPUART1() {
<re_irc>
USART6::on_interrupt();
<re_irc>
USART4::on_interrupt();
<re_irc>
}
<re_irc>
< (@dirbaio:matrix.org)> so you get the same but fully baked at compile time, no indirection
<re_irc>
< (@chemicstry:matrix.org)> ah, yeah that makes sense
<re_irc>
< (@dirbaio:matrix.org)> (this would replace the "owned interrupt" embassy has now)
wose has joined #rust-embedded
<re_irc>
< (@newam:matrix.org)> > These APIs are now usable in const contexts:
<re_irc>
> "<*const T>::offset_from"
<re_irc>
Other nice things for embedded from the 1.65.0 release 😃
<re_irc>
<brxken128> : that looks pretty great, thank you so much!
wose has quit [Ping timeout: 252 seconds]
emerent has quit [Ping timeout: 276 seconds]
emerent has joined #rust-embedded
wose has joined #rust-embedded
<re_irc>
< (@therealprof:matrix.org)> brxken128: They are working excellently...
<re_irc>
< (@therealprof:matrix.org)> They're very popular so there're also many examples around.
<re_irc>
< (@therealprof:matrix.org)> You might want to check out #rust-embedded-graphics:matrix.org (https://matrix.to/#/#rust-embedded-graphics:matrix.org) for indepth discussions about Rust and graphics on those displays, the driver authors for those driver chips also hang out there in case you run into problems. 😉
<re_irc>
<brxken128> thanks so much! i'll give it a join in the (somewhat likely) event that i need some help, it's my first time tinkering with displays so it'll be fun to learn
<re_irc>
<brxken128> cheers :)
<re_irc>
< (@lachlansneff:matrix.org)> Woot woot, embedded hal async on stable?
<re_irc>
< (@dirbaio:matrix.org)> no, it still needs TAIT
<re_irc>
< (@korken89:matrix.org)> It seems to me that it should work just as fine for single interrupt stuff as with peripherals that have shared interrupts
<re_irc>
< (@korken89:matrix.org)> Also doing the proc-macro for it will be trivial
<re_irc>
< (@korken89:matrix.org)> And the errors are quite nice and explanatory of what is wrong, very nice
<re_irc>
< (@korken89:matrix.org)> Especially as it checks both ways, one way using the vector name, other way with traits
<re_irc>
<brxken128> okay, complete shot in the dark but has anyone gotten esp32-s3 flash encryption working in rust? i know the HAL has some cryptographic primitives but i couldn't find anything online
Amanieu has quit [Ping timeout: 268 seconds]
Amanieu has joined #rust-embedded
GenTooMan has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
starblue has quit [Quit: WeeChat 3.0]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
starblue has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc>
< (@newam:matrix.org)> brxken128: You could also try asking in #esp-rs:matrix.org (https://matrix.to/#/#esp-rs:matrix.org) 🙂