stbenn commented on issue #16248: URL: https://github.com/apache/nuttx/issues/16248#issuecomment-2824480605
I was also leaning towards the second option, so I am glad to have confirmation on that. For either option, I was planning on keeping the API the same (for all the same compatibility reasons you explained) except for `stm32_dmasetup()` which will require a different configuration structure. However, this already seems to be the case between STM32 DMA implementations so I don't think that will be an issue. ### Focusing on Setup Configuration Current drivers give access to channel control registers, which works because those peripherals have most behavior defined in 1 or 2 (for H7 MDMA) registers. The H5 spreads it across 3 registers (or 7 for 2D channels), with one big caveat... common functionality like continuous DMA, circular buffer, and double buffer **are not register configurations**. This is why there needs to be at least some level of abstraction. There are three ways I can think of to do this, and I am open to other suggestions as well: 1. Define a structure to specify _behavior_ instead of registers. Have struct members for data size, address incrementing, burst length, etc. 2. Use pseudo-control registers. These would be well defined in the H5 DMA header file. Essentially the same abstraction as above, but packed into `uint32_t` with fields used to specify behavior. 3. Give access to `CxCR, CxTR1, CxTR2` registers and add an additional options member to turn on special modes (continuous/circular, double buffer, etc.). If a special mode is given, the DMA driver uses the provided control registers when allocating linked list items necessary for that mode. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
