-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
L4 integration: Adapted DMA to STM32L4 MCU series. #1916
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
Conversation
ab82d00
to
e87c524
Compare
9167980
to
1cc81ed
Compare
} dma_descr_t; | ||
|
||
#define DMA_TX_TRANSFER DMA_MEMORY_TO_PERIPH | ||
#define DMA_RX_TRANSFER DMA_PERIPH_TO_MEMORY |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tobbad why did you declare these 2 macros? Why not just use DMA_MEMORY_TO_PERIPH and DMA_PERIPH_TO_MEMORY directly? To me, these are much clearer in their meaning than tx/rx.
The way you have written the code is that each periph defines a As an alternative, how about the following: expose each entry of the
Does that make sense? |
Thank you - good point. I was as well not satisfied with my solution. Sometimes you have different alternatives for a periphery. Shall I call them eg. |
If they're not used, don't declare them, just leave them as commented-out code in case they are needed later. Otherwise, if they are used, put a postfix of |
I have now a solution at hand and debugging it. Is there an automated build, deploy and test framework for directly testing the code on a hardware? For the DMA I started to build some code which:
Is there a function in mp where I can get the information which is returned during a cold reset eg:
What I am interested in is the version, date, board and CPU information. |
Try os.uname() |
d5deeac
to
148035f
Compare
Thank you. I modified the PR according to your suggestions and collected all concerned file in this PR. I did some test (spi/i2c transfer on stm32f4disco and stm32l476disco) which passed. I hope that it can be merged now. |
I see that there are modifications to adc.c. Are they relevant to DMA? If not can you please separate the ADC changes into a separate commit (can be within this PR, just a separate commit to the DMA changes). Thanks! |
148035f
to
e0a2e58
Compare
#define NCONTROLLERS (2) | ||
|
||
#define DMA_TX_TRANSFER DMA_MEMORY_TO_PERIPH | ||
#define DMA_RX_TRANSFER DMA_PERIPH_TO_MEMORY |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tobbad why did you define these macros? To me it's clearer to just use the original mem-to-periph or periph-to-mem names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I defined theses macros to make the transfer of the information in the datasheet less error-prone. In the data sheet (RM0351, rev 2, Page 309 ff) there is always a SPI2_TX and SPI2_RX.. So I though it would be a good thing to define macros which are close to what is written in the datasheet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I see. But I still think using the macro adds unnecessary complexity. For example, in the datasheet there are also the names DAC1, DAC2, CRYPT_IN, CRYPT_OUT, TIM3_CH1, etc, that have nothing to do with tx/rx. So you can keep the names SPI2_TX etc, but just use DMA_MEMORY_TO_PERIPH and DMA_PERIPH_TO_MEMORY.
2a9d24a
to
7b061b8
Compare
@@ -33,9 +33,145 @@ | |||
#include "py/obj.h" | |||
#include "irq.h" | |||
|
|||
#define NSTREAMS_PER_CONTROLLER_LOG2 (3) | |||
#define NSTREAMS_PER_CONTROLLER (1 << NSTREAMS_PER_CONTROLLER_LOG2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As NSTREAMS_PER_CONTROLLER_LOG2 is 3 for F-series we have 8 streams. but on L4 there are only 7 streams. The use of this #define in dma_tickle is therefore no more possible. Therefore I removed NSTREAMS_PER_CONTROLLER_LOG2.
c138232
to
5c8c67e
Compare
.MemBurst = DMA_MBURST_INC4, | ||
.PeriphBurst = DMA_PBURST_INC4, | ||
}; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved to dma.c
.
Updated the code and did some clean ups. Did some simple i2c/spi test on stm32f4disco, stm32F429disco, stm32l4Disco, limifrog. |
5c8c67e
to
78457cd
Compare
I did a little bit of tidying up (mostly white space changes and reordering some things in dma.c) and merged it in e64032d. Thank you! |
Removed warning box regarding SAMD21 builds
This is the 5th PR in a series (#1888, #1890, #1903, #1904 ) of PR to support the STM32L4 series in micropython. (see http://forum.micropython.org/viewtopic.php?f=12&t=1332&sid=64e2f63af49643c3edee159171f4a365)
The topic is to change the dma code in a way, that the structure
DMA_Stream_TypeDef
(which is similar toDMA_Channel_TypeDef
on stm32l4) is no more used outside of dma.c as this structure only exists for F4 series. Therefore I introduced a new structure (dma_descr_t
) which handles all dma specific stuff for configuration. Further the periphery (spi, i2c, sdcard, dac) does not need to know the internals of the dma.As a consequence a Periphery just asks for a dma to it self (defined by the enum
periphery_t
in dma.h) which instance of it self, and the direction of data transport. The DMA module then decides upon the Stream/Channel (stm32f4) or Channel/Request (stm32l4) should be used. These configuration are captured in the dma_transfer_info structure within dma.c. Further the initial setting (DMA_InitTypeDefsdma_init_struct_spi_i2c
anddma_init_struct_sdio
) is as well centralized in dma.c as these are as well MCU series specific.This fix should work without the merge of the earlier PRs.