<JamesMunns[m]>
<JamesMunns[m]> "Not sure how it would fit into..." <- I think you really have two options:
<JamesMunns[m]>
1. Make a different interface that returns some kind of stream, so events aren't lost
<JamesMunns[m]>
2. Make a different interface, like WaitCell has, that allows you to "anchor" the future before awaiting. There's still a small window you could miss events, it's just smaller because it doesn't include the time spent on `do_something().await`.
<JamesMunns[m]>
<JamesMunns[m]> "Not sure how it would fit into..." <- I don't really understand what you mean by "rewinding the future".
<montymintypie[m]>
Oh it's not something that rust would let you do, I'm certain. Something like transmuting the future itself (and thus its state machine) into a byte buffer, then restoring that after the future is awaited. Truly horrific code-design.
<montymintypie[m]>
1. is interesting. In my hobby project (bluetooth mouse), I just need to know that _something_ happened so I can wake up and send a packet - it's ok if the inputs didn't change after all, but losing an edge means a button can be erroneously held down
<montymintypie[m]>
I'm currently tossing up between the "persistent events" approach (which involves a great deal of vendoring of the gpio hal code...) or just spinning my own ISRs that set a semaphore
<montymintypie[m]>
I'm more surprised that this race doesn't come up as a problem more often, the original conversation (and the mirrored github conversation) is the only comment I've found online about it, outside of the embassy RP hal which notes the race as a concern
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has quit [Ping timeout: 268 seconds]
<ckrenslehner[m]>
I can run the test on the wb55 tomorrow 🚀
isinfinity[m] has joined #rust-embedded
<isinfinity[m]>
I
pcs38 has joined #rust-embedded
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
<JasperHarrison[m> "Does anyone have any of the..." <- > <@legorooj:matrix.org> Does anyone have any of the following STM MCUs they can run a test on? I'd like to see if an embassy feature is working on them, as I suspect it is... (full message at
<JuanesPaz[m]>
<JasperHarrison[m> "Does anyone have any of the..." <- > <@legorooj:matrix.org> Does anyone have any of the following STM MCUs they can run a test on? I'd like to see if an embassy feature is working on them, as I suspect it is... (full message at
<JasperHarrison[m>
<dirbaio[m]> "You can test all these in the..." <- I've just double checked the lists I've got, and most actually are in the embassy test rack (I forgot to account for the fact that a lot of these chips are families and share the same hardware details in regards to this, however there's two which are not:
<JasperHarrison[m>
WLEx family
<JasperHarrison[m>
h723,h725,h730,h733,h735 - these are all one family, so results should be identical across them
<JasperHarrison[m>
So adamgreig and Juanes Paz if you're able to test these two that would be greatly appreciated, rust project below, you'll need to adjust `Cargo.toml` and `.cargo/config.toml` to have the correct chip, after that a simple `cargo run` will get you going.