| 2 Oct 2023 |
|  temp4096 joined the room. | 03:32:14 |
 korken89 | In reply to @davidcole1340:matrix.org
It doesn't seem like stm32f4xx-hal has support for embedded-hal-async, or is it hidden somewhere? The only HALs that I know of that has async support is embassy's :) | 03:52:23 |
| korken89 | No idea why the"good old" HALs don't add it | 03:52:54 |
| korken89 | In reply to @davidcole1340:matrix.org
So is it possible to use Embassy HALs with RTIC? Didn't realise that was an option! RTIC works with any HAL that's based on svd2rust or chiptool, which I think encompasses most HALs :) | 03:54:35 |
 David | I would like to stick with stm32f4xx-hal if possible, it seems to have better support for some things (like DMA) that I am using | 09:14:44 |
| David | I guess back to what I'm actually trying to achieve, I would like to define an async method that kicks off an operation like a DMA transfer in the background, at which point I would yield back to the scheduler. Then when the DMA complete interrupt comes in ideally I can wake that method back up. Is the core::task::Waker type safe to use in this context? | 09:19:23 |
 rtic-bot | New PR: Book: Restore missing newline | 10:20:44 |
 dirbaio | In reply to @davidcole1340:matrix.org
I would like to stick with stm32f4xx-hal if possible, it seems to have better support for some things (like DMA) that I am using stm32f4xx-hal doesn't support async. | 10:30:05 |
| dirbaio | what DMA support are you finding missing in embassy-stm32? | 10:30:21 |
| dirbaio | are you aware stuff like spi.write(&buf).await; uses DMA under the hood automatically? ie it's built into the peripheral drivers, there's no separate "dma" driver you need to use, unlike stm32f4xx-hal | 10:31:06 |
 burrbull | I think he is looking for pwm+dma | 11:07:47 |
| rtic-bot | New PR: Update stm32-metapac requirement from 13.0.0 to 14.0.0 | 17:02:03 |
| rtic-bot | PR merged: Update stm32-metapac requirement from 13.0.0 to 14.0.0 | 19:12:21 |
| David | In reply to @dirbaio:matrix.org
are you aware stuff like spi.write(&buf).await; uses DMA under the hood automatically? ie it's built into the peripheral drivers, there's no separate "dma" driver you need to use, unlike stm32f4xx-hal I'm using DMA to drive a PWM timer by writing to CCR to update the duty cycle | 19:15:06 |
| David | In reply to @dirbaio:matrix.org
stm32f4xx-hal doesn't support async. I guess with my second question I'm trying to get at implementing my own async without requiring implementation from the HAL | 19:15:33 |
| dirbaio | ah yeah that's missing from embassy-stm32 currently | 19:17:42 |
| dirbaio | (you could do it using the low-level embassy_stm32::dma api, but yeah..0 | 19:17:53 |
| dirbaio | * (you could do it using the low-level embassy_stm32::dma api, but yeah..) | 19:17:54 |
| dirbaio | if you want to roll your own, it goes something like | 19:18:20 |
| dirbaio |
- write a future that checks if DMA is done. if not done, store the waker somewhere (rtic resource maybe?), return Pending. if it is, return Ready.
- on irq, wake the waker.
- from the async task, await that future.
| 19:19:17 |
| David | (to be fair, it's missing from stm32f4xx-hal too, but I implemented it :P) | 19:19:21 |
| dirbaio | also care about race conditions, if you do "check if done, store the waker" you can lose the wake if the irq happens between those | 19:19:51 |
| David | In reply to @dirbaio:matrix.org
- write a future that checks if DMA is done. if not done, store the waker somewhere (rtic resource maybe?), return Pending. if it is, return Ready.
- on irq, wake the waker.
- from the async task, await that future.
The Waker - is this just the core::task::Waker type from the core libraries? | 19:19:54 |
| dirbaio | yes | 19:19:58 |
| dirbaio | you obtain it from the Context passed to future poll() | 19:20:12 |
| dirbaio | In reply to @dirbaio:matrix.org
also care about race conditions, if you do "check if done, store the waker" you can lose the wake if the irq happens between those so the easiest way is "store the waker first, then check if done" | 19:20:33 |
| dirbaio | In reply to @dirbaio:matrix.org
also care about race conditions, if you do "check if done, store the waker" you can lose the wake if the irq happens between those * so the easiest way to fix it is "store the waker first, then check if done" | 19:20:40 |
| dirbaio | you're essentially reinventing your own async HAL with this though 🙃 | 19:21:58 |
| David | Yeah, I will look more into embassy-stm32, the last time I had a proper play with it was over a year ago so I should give it another chance | 19:27:07 |
| David | Thanks for your help! | 19:27:09 |
