STM32: Can I DMA With An External ADC Through Parallel Protocol? - Page 1
Forum section: electronics / general

author: m.m.m
author_rank: Regular Contributor
timestamp: July 04, 2020, 12:24:44 pm
content: Hello,We're going to make an oscilloscope as a project for a course and we are going to use an external ~40MSPS ADC, and the ADC is going to talk with the microcontroller through the parallel protocol (8 bits).Since 40MSPS is going to be a lot of data obviously we can't just read the data using simple GPIO commands and write them into the MCU's RAM.So I was wondering whether it's possible to write the data without involving the CPU and so achieve higher speeds, or are we going to need an external SRAM (or FIFO memory) for that as a buffer.I had seen other projects using ADCs with DMA but all of them used some serial (e.g. SPI) protocol for the data flow.The MCU we're planning to use is anstm32f429zgt6

author: mjs
author_rank: Regular Contributor
timestamp: July 04, 2020, 02:32:06 pm
content: Check out the DCMI camera interface - it's pretty easy to misuse as ADC data input. Other option is FSMC external memory controller or plain old fast GPIO input.Your external memory requirements depends on what you need to do with the data - i.e. memory depth and whether you need some ADC data processin for triggering.

author: voltsandjolts
author_rank: Unknown
timestamp: July 04, 2020, 02:44:14 pm
content: You might find this interesting:https://www.eevblog.com/forum/projects/reverse-engineering-fnirsi-5012h/

author: MasterT
author_rank: Frequent Contributor
timestamp: July 04, 2020, 03:32:25 pm
content: There is app. note from STM: AN4666. It claims 6.67MHz – 7.82MHz sps. It's about match with my experience with stm32, DMA fastest transfer rate 1/12 main clock. Stm32H7 having 480MHz could reach 24 msps over DMA at max.

author: Yansi
author_rank: Super Contributor
timestamp: July 04, 2020, 03:54:39 pm
content: Not true. I think DMA bus turnaround is usually 6 cycles. Not 12, that seems like a nonsense. //EDIT: okay, for the GPIO cobbletogether maybe, but DMA turnaround should be 6 cycles if I remember correctly//And to the OP, if you want 40Msps oscilloscope, you should use CPLD/FPGA for the data acquisition anyway.At least use a cheap CPLD (Intel MAX V are dirt cheap nowadays) with a fast SRAM (10ns tRC/tWC asynchronous one for 40Msps is good enough) and then use the FSMC or FMC peripheral for data readout from the sample memory. This way you will not clog the entire CPU bus with DMA accesses and can use the burst functionality of DMA.

author: m.m.m
author_rank: Regular Contributor
timestamp: July 04, 2020, 05:55:47 pm
content: Thank you everyone for your suggestions. So Yansi you are suggesting that even if the DMA needs 6 cycles I could only get up to 30 Msps as my clock speed is 180 MHz? If that's the case then I think DMA is not fast enough for our project.My original plan was to put a FIFO memory with separate read and write clock inputs as a buffer between the ADC and the MCU, and fill the FIFO in a burst when the trigger event happens and then load the burst into the MCU with a lower speed clock, and the trigger would be masked until all the data is transmitted from the FIFO into the MCU and the required MCU processing time is passed.But then I read about DMA and thought maybe I can skip the FIFO part and directly connect the ADC to the MCU.So is there a way to directly use the ADC with the FMC interface? i.e. use the ADC digital output instead of an SRAM data output and then synchronize the ADC clock with the MCU clock using a PLL if needed, and configure the FMC in FIFO mode and just skip the address pins for the FMC? Is it faster than the DMA approach? Is it even possible?Unfortunately for some reason in this project CPLD and FPGA are not allowed.update:I just checked and it seems like the FMC can access an SRAM up to 90 MHz for a clock of 180MHz. So I should be able to do this without any issues right?

author: lawrence11
author_rank: Frequent Contributor
timestamp: July 04, 2020, 06:55:37 pm
content: These are things you should research yoursefl. I should call your professor and show him your lazy nature.

author: m.m.m
author_rank: Regular Contributor
timestamp: July 04, 2020, 07:23:02 pm
content: Quote from: lawrence11 on July 04, 2020, 06:55:37 pmI'm assuming you are already aware that we're in a pandemic and I can't just gather around with my teammates and discuss the project that is meant to be done as a group. So I have to communicate through messages and wait until they respond and that really affects the procedure, Not to mention that the online courses didn't teach us a single thing as well.And next time when you're calling someone lazy perhaps you should consider whether they have access to the same resources, parts, equipment, etc. that you have or not.And if you're not able to help me gather the necessary information on the topic you are free to leave the topic.

author: dave j
author_rank: Regular Contributor
timestamp: July 04, 2020, 08:17:02 pm
content: Quote from: m.m.m on July 04, 2020, 05:55:47 pmIt's a DMA transfer per 6 cycles not 1 byte per 6 cycles - a single DMA transaction can transfer 4 bytes.QuotePeople here are unlikely to know the answers to that off the top of their heads and would have to look it up in the MCU's datasheet. That is something you should be doing and is something people here and your professor would expect you to do. You can grab datasheets and example code from the manufacturer's web site - get your teammates to do this too, you will be able to research things separately and have a common document to refer to.You'll need to think how you are going to detect the trigger. A separate memory chip implies separate trigger detection hardware. The good news is, if you decide to transfer data directly from the ADC into the MCU you can check for the trigger using software fast enough for 40MSPS. That link that voltsandjolts posted earlier describes doing just that (well even faster) on a STMF4 clone. you should read all of that thread.

author: Yansi
author_rank: Super Contributor
timestamp: July 04, 2020, 08:59:04 pm
content: Quote from: m.m.m on July 04, 2020, 05:55:47 pmThe DMA is faster in burst mode I guess, 6 cycles is a single word transfer.Quote from: m.m.m on July 04, 2020, 05:55:47 pmThat is unfortunately not how DSOs work. You need to sample continuously and stop half the memory length after the trigger, so that you have half memory of pre-trigger samples!FIFO is not really a useful approach here.Quote from: m.m.m on July 04, 2020, 05:55:47 pmNo, this not possible with FMC. FMC can do very fast IO operations, but in sequential (burst mode), not at precise time intervals. With all the burst fifos in the peripherals and all the pipelining, achieving deterministic bus timing is almost impossible with these complex Cortex M microcontrollers.CPLD with address counter and simple asynchronous SRAM interface to store samples is the correct way to go. It is not even hard or complicated to do, not even expensive. You do not need a deep memory anyway, as your Cortex M microcontroller won't have enough grunt to process all of them. So couple K of SRAM is more then enough for a simple DSO.Quote from: m.m.m on July 04, 2020, 05:55:47 pmNo. It is a big difference of transferring sequential data and accessing data at precise time intervals - that is not easily possible. The Cortex M architecture is not really designed for this. FPGA/CPLD is the correct way for making a data acquisition with deterministic timing.Quote from: m.m.m on July 04, 2020, 05:55:47 pmThen you should argument why not allowing CPLD/FPGA is not really a great idea.The best approach you can have without a CPLD is using the DCMI interface. It has the required infrastructure in the MCU for moving large gobbles of data at precise time interval - the DCMI interface is a slave interface, you provide sample clocks to it. And it will run up to I think HCLK/3 rate maximum, so achieving 40 Msps should be easily possible. Although you will find other limitations of this.

author: MasterT
author_rank: Frequent Contributor
timestamp: July 04, 2020, 09:32:18 pm
content: Quote from: dave j on July 04, 2020, 08:17:02 pmDMA always transfer 32-bits, doesn't matter if data load byte, 2 or 4 bytes. The problem ( stm32 in particular) is that DMA has no means to pack unpack data between bytes and 4-bytes to accelerate transfer rate. A few peripherals , like ADC and DAC integrate their own "double mode" tricks, to pack two 12 bits words form both ADC or DAC into single 32-bits word. GPIO doesn't have such feature, so 8 MHz at max.I had some test, running stm32F446re (180 MHz) at 36 msps dma->gpio. There was no complain from software, but when I checked data at the port using synchronous external counter - I noticed that micro skipping some samples at random. Maximum glitch free rate I was able to get is about 11.25 msps. So, data sheet doesn't tell you much why this is happening.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 05, 2020, 06:20:08 am
content: Yes, try DCMI. It has an internal FIFO packaging the data to 32 bit transactions so that the DMA can work with 32 bits at once, four times less frequently than if you were doing 8-bit DMA transfers. The "cost" of DMA operation is the same whether it is 32 or just 8 bits of data so doing 8-bit transactions all the time really kills the performance.