10:47 <MartinSivk[m]> Good morning folks. I have a question about async GPIO Wait traits from embedded-hal. The short version is - anyone has an idea about how do I make sure there is no race condition between configuration of some device and the call to wait_for_low()? I tried asking in the project, but no answer yet (https://github.com/rust-embedded/embedded-hal/issues/653). Surely this pattern of 1. enable interrupts 2. configure device 3. wait

10:47 <MartinSivk[m]> for pin change can't be that unusual.

11:01 <JamesMunns[m]> Not sure how it would fit into the embedded-hal interface, but `maitake-sync` typically has `subscribe` methods that you can call to ensure the future is "listening" before you perform the triggering action: https://docs.rs/maitake-sync/latest/maitake_sync/wait_queue/struct.Wait.html#method.subscribe

11:04 <JamesMunns[m]> So, it might be worth it to have similar methods on e-hal methods to "anchor" the wait like with `subscribe`

11:04 <danielb[m]> in this case our future behaves somewhat naughtily, though, as you need to poll the driver an unknown amount of times before it actually starts listening

11:05 <JamesMunns[m]> oh? Why is that?

11:06 <danielb[m]> there is only a single interrupt handler for ALL gpios together, but two cores, and the possibility of user-registered interrupt handlers. The interrupt handler may actually be running on the other core while you start listening for a pin event, and the driver needs to wait for that handler to finish before it reconfigures the pin for the event you actually want

11:07 <danielb[m]> it's complicated and boils down to a weird decision where we allow user handlers and async operations on GPIOs

11:07 <JamesMunns[m]> Gotcha, we used to have a method that was more like:... (full message at <https://catircservices.org/_irc/v1/media/download/Abrn0EkElIZ-1RhYvhC6LyWpRZK_gn4TJ3gfGY3upA5etMwXPf9wP3CDlGmxcCw_235LUPWrNSZfr0W3mTWRwVO_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9JQWJmRVJodnJHYUdJRENLS1VyT0VFUUI>)

11:07 <JamesMunns[m]> so, that might be more appropriate, so you can await as many polls as it takes

11:08 <JamesMunns[m]> I think WaitQueue specifically can be done in one poll, maybe that's why we made the switch to a non-async method? I'd have to go back and look tho

11:09 <JamesMunns[m]> We also have methods like `wait_for`, which does the right thing in a polling loop, of always re-subscribing before checking the trigger condition: https://docs.rs/maitake-sync/latest/maitake_sync/struct.WaitCell.html#method.wait_for

11:09 <JamesMunns[m]> basically like a less-manual version of poll_fn

11:09 <danielb[m]> even funnier case is where the task that calls the GPIO wait runs above the priority of the GPIO interrupt handler - so blocking waiting for the handler to finish may be an infinite loop

11:17 <JamesMunns[m]> But yeah, typically:... (full message at <https://catircservices.org/_irc/v1/media/download/Af4WxV1aUh2y8P1lyF5CNoZ6yaJzSKXPlxg321EnkRTFsR63RGwJiwEFBrdqjbK9uE02ViXXfrjys8DEEBoLvmC_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9nUVlBT0ZvcllrcWZaSUVybnVHV093QkY>)

11:18 <JamesMunns[m]> but yes, it would be better if we could do something like:... (full message at <https://catircservices.org/_irc/v1/media/download/AUr7TiiLw4qGZmGVOwOrD2QZnPz-NMX0RW-KVoiXL6i8ZWDr2vJ-z97dkGL8ev5UhxpnEuX8GybnNI4ZeQnTSY-_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9yQWNEdmRMemRQenhuaWxhWVZVRkFlUkE>)

11:22 <JamesMunns[m]> Even stuff like:... (full message at <https://catircservices.org/_irc/v1/media/download/Aapn1Uaz2SXlkkXmMfa2pWpfkdI12qDi6cMASrqw_fXzjxCBw26uwMDX_waE4QwLBDz3kgaAWTHXww_fnNpDTRu_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9CUm1uTEFidm1leWFDaWlUeWhmeWVSUlA>)

11:23 <JamesMunns[m]> but for that you'd need some kind of counter or something that counts the number of "unyielded triggers", like an interrupt that counts up + wakes every time it happens, and a future that counts down every time the future returns Ready, and only returns Pending if the count is zero

11:27 <JamesMunns[m]> <danielb[m]> "even funnier case is where the..." <- I feel like this is something you could detect and panic on, honestly.

11:28 <JamesMunns[m]> it'd have to be done for like... everything though, which would be tedious and annoying :/

11:28 <danielb[m]> but it's not wrong 🤔

11:28 <JamesMunns[m]> like, have the driver store its prio level, and in the polling func check the current prio level, if it ever exceeds the stored level, panic

11:29 <JamesMunns[m]> danielb[m]: But it's also not ever useful?

11:29 <danielb[m]> who am I to say that :D

11:31 <JamesMunns[m]> I dunno if esp32 has the ability to see the current execution context (in interrupt, prio level) like cortex-m does, but on cortex-m I think it is possible.

11:39 <danielb[m]> ah yeah it's probably incorrect, you should have said that :D

11:40 <danielb[m]> wake_by_ref in an interrupt executor isn't a great idea

11:40 <vollbrecht[m]> also funny when you have a broken edge trigger ( e.g hardware bug) as in the classical esp32 :D E.g you cannot reliable use edge-triggers because under certain conditions the 32bit GPIO status register cannot be updated, if at the same time a interrupt status clear is run. The only workaround is using level-trigger there, wich fundamently works differently, and has its own kinda worms.

11:40 <JamesMunns[m]> "userspace" code with higher prio than "interrupt" code is probably isn't ever a great idea :p

11:40 <danielb[m]> vollbrecht[m]: wtf

11:41 <danielb[m]> the esp32 is such a mess of a chip

11:41 <danielb[m]> sometimes the DMA forgets to write back how much it read

11:41 <danielb[m]> I think our errata should be about the length of the reference manual

11:42 <vollbrecht[m]> * is run. ( This misses edges that happend) The only

11:42 <JamesMunns[m]> I wish vendors would start just inlining errata in the reference manual, instead of making them separate docs

11:43 <danielb[m]> i wish we had decent documentation

11:43 <danielb[m]> 😂

11:43 <danielb[m]> technically everything is inlined into esp-idf :D

11:43 <JamesMunns[m]> like info/warning boxes, or actually removing things from the RM that were impossible (like the stm32 CAN thing that just never worked)

11:49 <dngrs[m]> You'd absolutely love the USB video spec PDF which is just a collection of cross references that aren't hyperlinked

16:49 <MartinSivk[m]1> Depending on the runtime. I actually implemented my own simple no_std runtime that only sets a flag and places the job id into the queue during the wake() call. Fast, no side effects, no synchronization (except disabling interrupts for the atomic set).

16:49 <MartinSivk[m]1> Works perfectly fine, at least on single core stm32..

16:51 <MartinSivk[m]1> Thanks, this looks like a possible solution. But yes, it is clunky.

16:55 <MartinSivk[m]1> I am currently using a simplified version of that style. let wait = pin_w_irq.wait_for_low(); setup(); wait.await; The initial wait method subscribes and returns the future impl. But I was hoping to modernize my code and migrate to the embedded_hal_async style. Alas, this pattern does not currently fit its model.

16:56 <MartinSivk[m]1> On a side note.. I wish I had more time to send couple of PRs to the stm32l0x1_hal crate too, it is still based on the 0.2 traits.