Skip to content
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

Draft
wants to merge 18 commits into
base: main
Choose a base branch
from

Conversation

xC0000005
Copy link
Contributor

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.

@xC0000005
Copy link
Contributor Author

Just discovered (thanks to the CI checks) there are boards which share interrupts between instances and channels. I'll look into it tonight.

@fpistm
Copy link
Member

fpistm commented Dec 11, 2019

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

@xC0000005
Copy link
Contributor Author

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.

@fpistm
Copy link
Member

fpistm commented Dec 12, 2019

dma.h can be kept in the core. Only the source c file have to be in the builtin SrcWrapper library.

@geosmall
Copy link
Contributor

geosmall commented Dec 19, 2019

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.

@xC0000005
Copy link
Contributor Author

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).

@xC0000005
Copy link
Contributor Author

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.

@matthijskooijman
Copy link
Contributor

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...

@fpistm
Copy link
Member

fpistm commented Jan 2, 2020

@matthijskooijman
Thanks for sharing.
That should be fine to have an unified API.

@xC0000005
Copy link
Contributor Author

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.

@CJT1111
Copy link

CJT1111 commented Nov 7, 2023

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

None yet

5 participants