-
Notifications
You must be signed in to change notification settings - Fork 958
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft - Dma Handlers in Arduino core #825
base: main
Are you sure you want to change the base?
Conversation
c72c207
to
d685c19
Compare
Just discovered (thanks to the CI checks) there are boards which share interrupts between instances and channels. I'll look into it tonight. |
Hi @xC0000005 |
I'll work on this more tomorrow to add a test sketch and fix the compile issue, once I re-setup my git repo for use with the arduino IDE. |
dma.h can be kept in the core. Only the source c file have to be in the builtin SrcWrapper library. |
I few months ago I developed a HAL LL based TIM-DMA DShot streaming serial protocol implementation (see here for F411 example https://www.rcgroups.com/forums/showthread.php?3347115-Dshot-ESC-Protocol-on-STM32F4-using-Arduino). Will implementing this change break sketches like this that use DMA interrupts directly, forcing sketch writers into this implementation? If so I would request that some path (include as library not core, or perhaps build_opt.h defines?) be made available for sketch level DMA interrupts. |
It absolutely would break them, much like having timer handling in the core broke sketches with timer interrupts - I'll look at what's done with the timers to prevent that and see if I can do the same for DMA (or if the timer IRQ handlers have any such mechanism). |
Working on getting my example sketch running again - it uses a neopixel to demonstrate. Once I do, I'll compile for the boards that are failing and see what I need to do to make it work. |
This PR somewhat relates to arduino/ArduinoCore-API#93 which is about providing a (possibly portable) DMA API for official Arduino cores. Ideally, the STM32 API would be the same or at least similar to the official API, with the caveat that there is no real movement on an official API yet... |
@matthijskooijman |
I agree about the shared API - if you look at older versions of this PR, you'll see I'm privately experimenting with a library that looks very similar to the ZeroDMA/proposed one. One of the bigger issues with this is that ST hardware has some specific constraints on what can DMA to where. I can't, for instance, allow someone to simply say "Memory Transfer to SPI1" (yet). That implies I need to have a mapping somewhere, preferably built from a CSV or data table, of what can transfer to where. Instead of tackling that, I split it down and said "What's the simplest thing blocking?" and the answer is "Sketches should, like the timer functions, register for call backs." I have this working again, now I have to get the Neopixel sketch updated, and test on the boards that don't compile and fix them. So this PR won't get us to a single shared API, but it will set the foundation for a DMA library that could do exactly this. |
Do you mean that you have written library functions that DMA calls directly under the environment of Arduino IDE for STM32? |
Summary
This PR fixes/implements the following bugs/features
Draft which creates DMA IRQ handlers in the arduino core, meaning that libraries/sketches should not define them, instead using prepare/end to register for callbacks. This means that if three libraries all use DMA on different channels there's no conflict in the interrupt handlers being defined in each.
I'll be deleting the library shortly (as soon as I figure out how to squash all of these and leave only the dma.c/h files. I'm sharing to see if this would be useful for other people.
I have a WSB LED sketch that illustrates this, but there may be a better way to illustrate.
Validation