Arduino_Core_STM32
Arduino_Core_STM32 copied to clipboard
stm32duino
Draft - Dma Handlers in Arduino core
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
- Ensure Travis CI build is passed.
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
Thanks for this draft PR.
First remark, you have to move the dma.c in the built-in library SrcWrapper/src/stm32, this will ensure the non weak IRQHandler definition will be used: #811
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.
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 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.
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 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 https://github.com/arduino/ArduinoCore-API/issues/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 Thanks for sharing. That should be fine to have an unified API.
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.
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
- Ensure Travis CI build is passed.
Do you mean that you have written library functions that DMA calls directly under the environment of Arduino IDE for STM32?
