Re: PWM and code in the main loop
Posted: Sun Mar 16, 2025 6:05 pm
if you are using the 'official' corejulian_lpp wrote: Sun Mar 16, 2025 3:10 pm well, I'll start investigating about DMA and Timer combination, maybe with gpt help to speed it up, given that never looked into dma stuff, hardly imagine what it is, but need to figure out exacly how it works, how to configure a timer to start reading a buffer and increment its index, the way and order irqs are triggered, etc, etc
All your comments were higly valuable, and as soon as I can get some code to post i''ll do. Hopefully we could contibute with some usable code where neopixels management are part of much complex program, rather than adafruit approach that pretty much is "drive your leds and the rest of the code who knows"
kind regards
julian
https://github.com/stm32duino/Arduino_Core_STM32
here are some tips to get started,
use the STM32CubeIDE to generate codes for DMA and timer
https://www.st.com/en/development-tools ... beide.html
that would generate some codes for setting up DMA and Timer using HAL function calls, setting up the interrupts etc.
you can then copy over the codes and work on them over in a STM32Duino project.
of course searching the web for examples, tutorial or even using ChatGPT etc would help too,
I tried that in a while trying to make a SPI lib with DMA here
viewtopic.php?t=2553
https://github.com/ag88/stm32duino_spi_dma
one of the major challenges is that practically across the different series, each series has a different DMA controller, so they work a little differently say between stm32 F1, F4, G4, H5, H7, F0, F3, L4 etc
I end up abstracting codes into c++ classes, so that codes that I can reuse across the series is perhaps in one class
https://github.com/ag88/stm32duino_spi_ ... SPIDMA.cpp
and the derived series specific class would implement the different part (especially DMA) specific to each series, e.g. for F4xx
https://github.com/ag88/stm32duino_spi_ ... A_F4XX.cpp
all my codes there currently build ok with CMake, in STM32Duino but that I've not physically tested them unfortunately
if you'd like you could try this way say with what you have on hand, e.g. generate codes for stm32f103 in STM32CubeIDE, adapt it to work in stm32duino, and later if we'd want to make that 'generic', we'd need to consider these challenges, say in making a library.
A thing is if codes are specifically written only for stm32f1 (say f103), there may be challenges later when trying to port that say into F4 or a G4 chip/board. i'd guess it make sense to prioritise portability these days, there are many newer or different chips e.g. F4, G4, F7, H7, H5, L4 these days, many are faster/better that the stm32f103.
But that doing so would mean to confront all those challenges e.g. about chip differences (e.g. DMA) between the serieses , and it'd likely result in more code bloat (if-defs), use more memory (memory is especially precious, with the smaller chips) and flash, bigger/fatter binaries etc.
But not doing so may make the same code base 'un-usable' say across a series e.g. can't 'just works' when trying to use that for an F103 say later for F4, G4 etc.