<ryan-summers[m]> That probably means the register is write-only then. Check out the reference manual - if it is actually readable, there may be a bug in the SVD
<chmanie[m]> Ah yeah that's probably true
<chmanie[m]> At least it doesn't really make much sense to read from it
<chmanie[m]> Thanks ryan-summers
<ryan-summers[m]> If it's a write-only reg, it probably means that it's a set/clear type register, so the actual value of it is often dont-care
<chmanie[m]> ```rust
<chmanie[m]> ```
<chmanie[m]> unsafe { (*pac::USART1::ptr()).rqr.write(|w| w.rxfrq().set_bit()) }
<chmanie[m]> That seems to be fine
<firefrommoonligh> You're correct; that line is how you do it. Error in my example
<firefrommoonligh> Interrupt clearing code is usually like this. You read interrupt flag in one reg, and write in another. Often ISR to read, and ICR to write. Depends on MCU and periph
<firefrommoonligh> And you clear the flag by setting a bit, which can be confusing if you're not used to it
<chmanie[m]> I was missing this line in the other hals' examples: https://github.com/David-OConnor/stm32-hal/blob/main/examples/serial_nonblocking.rs#L61
<chmanie[m]> I was used to setting up the interrupt like this using the official STM hal. Are the other hals just hiding it very well or is this something that's abstracted by something like `rtic`?
<ryan-summers[m]> Most HALs don't set up ISRs for something like UART. They just poll status flags
<chmanie[m]> Is it possible to return a value from an interrupt::free closure to the non-free scope?
<chmanie[m]> * Is it possible to return a value from an `interrupt::free` closure to the non-free scope?
<chmanie[m]> I assume it's wise to keep the `free` as small as possible
<chmanie[m]> Ah, never mind, I'm stupid 🤦
<Lumpio[m]> I wonder if anybody has tried to figure out a way to get HALs to manage and create ISRs
<dirbaio[m]1> embassy does that, it has an "owned interrupts" abstraction similar to owned peripherals
<dirbaio[m]1> drivers ask the user to pass the owned interrupt in, and register their handler
<firefrommoonligh> I considered HAL assisted ISRs, but chose not to. Instead, I've chosen to provide periph struct methods to enable and clear interrupts
<firefrommoonligh> * I considered HAL assisted ISRs, but chose not to. Instead, I've chosen to provide periph struct methods to enable interrupts, and clear their flags
<firefrommoonligh> Most of the examples I've added include interrupts. IMO they're a common and important feature of embedded. So, even though they're largely decoupled from the HAL itself, I include them since they'll be part on any program
<firefrommoonligh> * Most of the examples I've added include interrupts. IMO they're a common and important feature of embedded. So, even though they're largely decoupled from the HAL itself, I include them since they'll be part on any program that uses the HAL. And I want to show sharing state of HAL periphs between contexts etx
<firefrommoonligh> And for someone new to embedded or rust to be able to copy an example and apply it to his or her project
<firefrommoonligh> That particle example is a bit of a mess - sorry, will clean it up
<chmanie[m]> I finally made it work using interrupts and a heapless queue. I'm quite pleased with how simple it turned out to be in the end
<firefrommoonligh> * That particular example is a bit of a mess - sorry, will clean it up
<firefrommoonligh> Awesome
<chmanie[m]> Thanks again for the help!
<firefrommoonligh> Glad it worked out
<chmanie[m]> I think I might be able to help fix that example
<firefrommoonligh> * Most of the examples I've added include interrupts. IMO they're a common and important feature of embedded. So, even though they're largely decoupled from the HAL itself, I include them in examples since they'll be part on any program that uses the HAL. And I want to show sharing state of HAL periphs between contexts etx
<chmanie[m]> If you're fine with it, I'll take a stab.
<firefrommoonligh> Def!
<firefrommoonligh> But ... Please wait until later today. I need to fix several errors
<firefrommoonligh> I'll let you know
<chmanie[m]> Ok, of course! Cheers!
<BobMcWhirter[m]> I'm looking at adding H723 to embassy/metapac, which currently consumes stm32-rs SVDs, which lacks H723
<BobMcWhirter[m]> PR an update to the h7.zip in vendor?
<BobMcWhirter[m]> wait, nevermind
<chmanie[m]> I'm following [this example](https://doc.rust-lang.org/stable/embedded-book/start/exceptions.html#a-complete-example) to set the system tick reload time but for some reason it's not reflected in the behaviour or the call to `cortex_m::peripheral::SYST::get_reload();` which yields the very weird number of `12891136`
<chmanie[m]> * I'm following [this example](https://doc.rust-lang.org/stable/embedded-book/start/exceptions.html#a-complete-example) to set the system tick reload time but for some reason it's not reflected in the behaviour or the call to `cortex_m::peripheral::SYST::get_reload();` which yields the very weird number of `12891136`. Is there something I could be missing?
<BobMcWhirter[m]> okay, back to h7... there is a newer (by 2 years) .zip of h7 SVDs. the h7b3 has renamed the clock domains, so I'm working through that.
<BobMcWhirter[m]> the question is: do we stick with (and rename to) stm32-rs'
<BobMcWhirter[m]> * the question is: do we stick with (and rename to) stm32-rs's names, or adjust patches to work against latest ZIP?
<firefrommoonligh> chmanie: Updated nonblocking serial example; ready for PR. I won't touch that file