stm32f0xx-hal
stm32f0xx-hal copied to clipboard
stm32-rs
Shamelessly copy DMA implementation from stm32f1xx-hal crate.
This PR adds DMA interface created using embedded-dma traits, that was copied from the stm32f1xx-hal crate and adapted for the needs of STM32F0 controller line.
DMA2 for STM32F091 was not yet added as to my understanding it requires some special handling.
Very nice! Obviously needs some more work though. I'd probably split out the stm32f0 bump to see whether there's any fallout from that upgrade (and fix it) before adding DMA.
Good idea, I’ll make a separate PR for updating dependencies and have a look at the failing CI.
![bors[bot] avatar](https://avatars.githubusercontent.com/in/1847?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hi, the PR still doesn't pass CI as the f1xx-hal uses #[non_exhaustive] feature on enums and they do not specify the minimum supported Rust version. I think that we shouldn't specify the MSRV as of now, since this HAL implementation is very limited and I am willing to start working on it and bring it up to the at least the same level as the other HALs and fixed MSRV could potentionaly cripple the development. What do you think @therealprof ?
Removing he non_exhaustive attribute is not a problem, but it would break the cross HAL compatibility.
I'm not a big fan of MSRV in general. Let's just bump the version in CI.
Ok, I'll make the PR when I have time in a few days. Should I remove checking against some specific rust version in general or just bump the specified version to a current Rust version?
What about the timing out bors? Do you have any idea why it fails? Fix for it could also be a part of that PR.
@therealprof Sorry for ignoring my PRs and you, I am a bit busy and don't develop on F0 often nowadays. I have the work on these PRs on my TODO list and will get back to them when I have a bit more time - unfortunately in June.
No worries, I can totally relate. Busy times with unrelated things for me as well...