| 28 Jul 2021 |
 firefrommoonlight | Exquisite timing | 13:30:23 |
 dirbaio | This will use DMA:
let mut spi = Spi::new(
p.SPI1,
p.PB3, p.PB5, p.PB4,
p.DMA2_CH3, p.DMA2_CH2,
Hertz(1_000_000),
Config::default(),
)
This will use good old cpu-copying
let mut spi = Spi::new(
p.SPI1,
p.PB3, p.PB5, p.PB4,
NoDma, NoDma,
Hertz(1_000_000),
Config::default(),
)
| 13:30:48 |
| dirbaio | but yeah it's quite opinionated, this means you can't use all the weird custom fancy DMA pacing/timing/request generation stuff | 13:32:16 |
| dirbaio | maybe embassy will expose a lower-level unsafe api where you can configure all that stuff | 13:32:47 |
 thalesfragoso | In reply to @firefrommoonlight:matrix.org
And IIRC, the biggest safety concern with the interface I posted exposes is the buffer being dropped while a DMA operation is in progress Not only being dropped/forgotten in your case, since you don't have a Transfer type, the user can just continue using the buffer | 13:33:21 |
| thalesfragoso | So I think it's quite dangerous | 13:33:27 |
| firefrommoonlight | Good point | 13:33:54 |
| thalesfragoso | I would recommend doing a transfer type that at least borrows the buffer | 13:34:01 |
| thalesfragoso | It would still be unsafe, but way less | 13:34:15 |
| dirbaio | +1 to Transfer type, it'll make the borrow checker prevent the obvious ways of shooting yourself in the foot | 13:34:55 |
| dirbaio | you can even have Transfer's drop gracefully stop DMA | 13:35:08 |
| firefrommoonlight | From an API perspective, what dirbaio just posted is outstanding. I don't think it's possible without HAL managing interrupts to some extent | 13:35:09 |
| dirbaio | at that point the only wya to trigger UB is to leak the Transfer (with eg mem::forget) | 13:35:31 |
| dirbaio |
I don't think it's possible without HAL managing interrupts to some extent
With blocking read/write you can just spin on DMA finishing. With async yeah you need the HAL to own the interrupts
| 13:36:02 |
| thalesfragoso | In reply to @firefrommoonlight:matrix.org
From an API perspective, what dirbaio just posted is outstanding. I don't think it's possible without HAL managing interrupts to some extent You can have a method to check if it's complete and a stop/finish method | 13:36:44 |
| thalesfragoso | Then you can let the user call them as they prefer | 13:37:08 |
| firefrommoonlight | Yeah; to block you could just poll the tx complete etc flag then return, but at that point, you lose a big adv of DMA | 13:37:15 |
| thalesfragoso | Be it on interrupts or from time to time, or just block on it | 13:37:23 |
| firefrommoonlight | * Yeah; to block you could just poll the tx complete etc flag then return, but at that point, you lose a big adv of DMA | 13:37:24 |
| dirbaio | dma is still useful with polling | 13:37:35 |
| dirbaio | user can start 10 DMA transfers at once then wait for all to finish | 13:37:48 |
| thalesfragoso | Even without the interrupts, the user can still do some unrelated work and then poll later | 13:38:00 |
| dirbaio | where it really shines is async though 😜 | 13:38:19 |
| firefrommoonlight | That works too, and would make for an easy API. I'm using a working assumption that practical uses will involve an interrupt. Maybe that's a good assumption - and maybe not | 14:06:04 |
| firefrommoonlight | In reply to @thalesfragoso:matrix.org
You can have a method to check if it's complete and a stop/finish method * That works too, and would make for an easy API. I'm using a working assumption that practical uses will involve an interrupt. Maybe that's a good assumption - and maybe not | 14:06:15 |
| firefrommoonlight | edit: NVM, that's a good point re multiple tranfsers and polling | 14:06:46 |
| firefrommoonlight | or start, and poll at arbitrary later point | 14:07:54 |
| firefrommoonlight | I think this will make more sense after I use it more | 14:08:04 |
|  damccull joined the room. | 15:50:02 |
 9names | DMA is lower power and can also be faster than CPU, since it can (potentially) do a load+store on different busses in a single cycle | 23:26:02 |
