Looking for Cortex-M3 or M4 with DMA to GPIO capability - Page 1
Forum section: electronics / general

author: poorchava
author_rank: Super Contributor
timestamp: April 24, 2013, 08:13:46 am
content: Hello,I have a project which requires MCU to generate data and send it at high speed to an FPGA. ARM Cortex core is a requirement.The intended way how this is supposed to work is-processor generates data and places into an array-timer interrupt initiates a transfer from the data array to GPIO.-DMA is expected to - once set up- transfer one chunk of data of fixed size (16 bits) to GPIO and advance the DMA address register to another cell in the array-DMA stops at the end of array and this has to be able to generate interrupt for the processor to know that it has to repopulate the arrayNow the problem is, that GPIO<->DMA transfers seem to be largely omitted by chip manufacturers. I have found a mention, that some LPC families allow such transfer as memory-to-memory transfer into the address space occupied by GPIO registers, but I couldn't find any particular code example or application note that would confirm that. On top of that I'm kind of biased towards STM32 family.So the question here is: do you know of any widely available, open-source/free toolchain friendly Cortex-M3 or M4 MCU that you know for sure that can do this kind of thing? I would prefer something from bigger players like ST, NXP, TI, Atmel.

author: BravoV
author_rank: Super Contributor
timestamp: April 24, 2013, 09:22:35 am
content: Not claiming an expert, infact the new TI ARM-M4F is my first Arm and I'm in the middle of drowning in their tons of documents, coincidentally I just passed the DMA section, these are the quoted from technical datasheet and the DMA API summaries, hope this helps.DMA specification from datasheet :QuoteFrom the DMA API documentation :Quote

author: Memphis
author_rank: Contributor
timestamp: April 24, 2013, 09:51:59 am
content: Why do you not using FSMC in STM32(F2,F3,F4)?It can be driven via DMA. Data can be outputted with parallel 16bits pins + some control signals such as addressing and control lines, which of course can be used for anything you want.

author: nctnico
author_rank: Super Contributor
timestamp: April 24, 2013, 07:43:07 pm
content: I'd use the ethernet MAC. You simply dump data into it without any protocol.

author: andyturk
author_rank: Frequent Contributor
timestamp: April 24, 2013, 10:24:18 pm
content: Quote from: poorchava on April 24, 2013, 08:13:46 amI'm pretty sure the STM32's DMA will do exactly that. Just make sure to use a DMA channel that isn't being used by another peripheral. You should be able to configure it to do 16-bit writes and increment the source by 2 bytes each transfer. The destination address won't change (i.e., it's always the same GPIOx_ODR register).

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 24, 2013, 10:36:45 pm
content: NXP LPC1800 will do DMA to peripherals - not sure offhand which peripherals but SDHC is one of them, which should give a fairly decent data rate & be easy to interface to an FPGA.Another option may be to use an ARM that supports external memory, and have the FPGA pretend to be external RAM

author: jmole
author_rank: Regular Contributor
timestamp: April 24, 2013, 11:08:14 pm
content: I'll toot my own horn here and recommend the Cypress PSoC 5 LP.Rather than DMA, per se, you can write a simple verilog component with a CPU accessible data register, and then latch the register value to GPIO on any digital signal, internal or external.The toolchain is proprietary, but completely free (with full functionality). It actually uses GCC underneath everything else for the C code compilation.I make a dev kit for it calledfreeSoC, and Cypress recently announced a low-cost PSoC 4 board (same digital flexibility, but a slower proc) calledPSoC Pioneer.

author: westfw
author_rank: Super Contributor
timestamp: April 25, 2013, 02:14:27 am
content: QuoteWouldn't that be the default assumption, for an architecture with a single address space?

author: poorchava
author_rank: Super Contributor
timestamp: April 25, 2013, 06:22:36 am
content: I meant that when setting up various stuff when initializing DMA, for example SPI or UART will be a peripheral-to-memory transfer, whereas GPIO is in most cases referred to as memory-to-memory transfer.As for TI Stellaris/TivaC I think they have a very rich feature set, but they are a very young product (did they hit series production yet?).Quote from: Memphis on April 24, 2013, 09:51:59 amThat sounds like a viable idea.I will need to read a bit more on how FSMC works. I want to keep protocol between devices very simple, because I don't have funds to buy and IP core for some fancy protocol (I'm not an expert on fpga/pld design either). Device used will most likely be Lattice MachXO2-1200HC-6TG100I. The solution can be crude but has to be fast

author: Memphis
author_rank: Contributor
timestamp: April 25, 2013, 07:38:53 am
content: Quote from: poorchava on April 25, 2013, 06:22:36 amThe best thing about FSMC is that it has a linear address space, so outputting data is trivial and fast and also can be synchronized with clock.For example i did connected SSD1963 (which is TFT controller) thru FSMC for speed reason. And the result is that i can play uncompressed images at 25-30fps just by using DMA copying data from SDCARD to FSMC with some internal buffering.

author: knik
author_rank: Newbie
timestamp: April 27, 2013, 07:51:53 am
content: I'm not sure about GPIO output but I tested input GPIO->DMA (no FSMC) on STM32f103 and it seems to work well.DMA peripheral addr set to GPIO->IDR and it works, max speed is limited to about 6 Mtransfers/sec.

author: andersm
author_rank: Super Contributor
timestamp: April 27, 2013, 12:01:00 pm
content: Quote from: knik on April 27, 2013, 07:51:53 amDoes the speed change if you change the IO pin max output speed? Ie. does the peripheral limit the transfer speed to what the IO pins are actually capable of?One advantage of using an external bus interface is that you get the strobe signals for free. The DMA peripheral may not be able to guarantee a consistent data rate (eg. does the transfer stall every time the core reads or writes to memory or another peripheral?), so the receiving should be prepared to handle that. If not all IO port bits are needed for data, one could be used as a clock signal.

author: poorchava
author_rank: Super Contributor
timestamp: April 27, 2013, 02:28:04 pm
content: I've done some reading about FSMC and asynchronous SRAM and I think it should do the job. Since I'm communicating with FPGA (or maybe CPLD) I can easily implement an SRAM interface. Thay way I should be able (on top of high speed transfer using DMA) to write to FPGA as I would to a normal variable (FSMC maps the external SRAM to normal data memory address space).First goal is to turn an FPGA into a variable bitrate serializer that can achieve at least 40 Mbps. So with 16-bit bus width theoretically 2.5M transfers /s should be enough.I think I will settle with STM32F103 with 1Mbit flash in 144pin QFP.

author: free_electron
author_rank: Super Contributor
timestamp: April 27, 2013, 03:23:35 pm
content: Quote from: mikeselectricstuff on April 24, 2013, 10:36:45 pmThat's the way i do it. Get a cpu with the EMIF ( external memory interface) exposed ( typically those are the vety high pincount beasts)

author: nctnico
author_rank: Super Contributor
timestamp: April 27, 2013, 05:51:04 pm
content: IMHO the ethernet MAC is the best way to go. In NXP's ARM devices the ethernet MAC has an SRAM buffer connected to a different memory bus so DMA transfers are not colliding with data and instruction fetches for executing code. Another advantage is that the MAC is clocked by the external device so you can use the FPGA's internal clock (which doesn't need to be 50MHz; I even implepemented bit-banging ethernet PHYs). The MAC is doing all the clock domain crossing work for you.

author: westfw
author_rank: Super Contributor
timestamp: April 27, 2013, 10:58:57 pm
content: QuoteIs the interface to the Phy usually only 4bits (or less) wide? I guess GMII has 8bits for Gigiabit ethernet, but I can't say as I've ever seen that on a microcontroller-like part.Using the Mac as a general-purpose dma'ed interface is an interesting idea, though. Has anyone done video that way?

author: knik
author_rank: Newbie
timestamp: April 28, 2013, 02:55:32 pm
content: Quote from: andersm on April 27, 2013, 12:01:00 pmTo me it looks like DMA speed limit, it would need a bit more than 10 cycles per transfer, it just misses some transfers when timer trigger is too fast.I haven't tested different pin speeds but I think it doesn't matter when you use it as input.If FSMC is used with DMA I wouldn't be surprised if it turned out as fast as DMA+GPIO.

author: saigai
author_rank: Contributor
timestamp: April 28, 2013, 08:49:51 pm
content: Quote from: poorchava on April 24, 2013, 08:13:46 amI did GPIO<->DMA like this on an LPC1768, but the opposite way. Maybe the code would be helpful to you, though:https://github.com/desaster/grabor/blob/master/src/dma.c(currently this code is actually unused in the project)

author: Rasz
author_rank: Super Contributor
timestamp: February 03, 2015, 10:32:59 pm
content: http://www.arrownac.com/manufacturers/stmicroelectronics/stm32-primer/appnote.pdfhttps://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Data%20transfer%20from%20GPIO%20port%20to%20RAM%20buffer%20using%20DMA%20upon%20receiving%20a%20trigger%20signal%20on%20the%20timer%20capture%20input%20channel&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=660https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a//my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/DMA%20MemoryToMemory%20using%20Timer%20for%20delivery%20rate&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=102stm32F103 should do it with no problembtw Stmicro forum is soo garbage :/

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: February 03, 2015, 10:45:14 pm
content: I second the LPC1768. It has a pretty capable DMA.Did some VGA demo stuff some years ago where more or less the complete VGA signal creation was DMA based.Alsomy little engine signal generatormakes heavy use of DMA.

author: tymm
author_rank: Contributor
timestamp: February 04, 2015, 04:16:42 am
content: STM32 (and even down to ST's Cortex-M0 parts) will allow you to DMA to GPIO if you're willing to coax them a little. I do plenty with GCC on the M0's & M3's.Unfortunately their documentation on this (and in general how the DMA controllers work) is terrible and this hides lots of useful possibilities.IIRC, yes you just set it up as a memory-to-memory transfer, point the destination register at the GPIO's output data register (ODR) and disable auto increment on the destination address (it's been a little while since i poked at the specific problem, but I'm almost positive there's not much more than that). Simplest is if you're DMAing to a whole GPIO port at once; if you're picking and choosing the pins it can get more complicated - though the "bit banding" on many M3's is one way to simplify that.

author: andersm
author_rank: Super Contributor
timestamp: February 04, 2015, 08:48:45 am
content: Quote from: tymm on February 04, 2015, 04:16:42 amMost, if not all, manufacturers have ways to set individual GPIO pins. Eg. ST have bit set/reset registers, and NXP have a very unusual method where the LSBs of the address used to access the port become a mask.

author: miceuz
author_rank: Frequent Contributor
timestamp: February 04, 2015, 08:51:10 am
content: This project is using DMA on Freescale Kinetis K20 to bit bang data for ws2812 leds on a 8-bit port:https://github.com/scanlime/fadecandy

author: Yansi
author_rank: Super Contributor
timestamp: February 04, 2015, 09:04:31 am
content: Quote from: poorchava on April 24, 2013, 08:13:46 amRegarding that ARM is Von Neumann architecture, so it has only one memory space and memory mapped peripherals, where the hell is the problem to tell the DMA controller to puke data into GPIO?I don't know how well perform other ARM vendors at this, but on STM32 the DMA to GPIO transfers work pretty well and suprisingly some people use that.The DMA controller is a universal block, you only tell it the address to start from and where to copy it. There aren't any restrictions known to me for what address it can be used.As it was maybe pointed out, for an FPGA you need synchronous or strobed datatransfer, rather then spewing it through GPIO. Use the external bus out of the MCU (FMC or FSMC peripheral on STM32). It can do strobed (asynchronous) or clocked (synchronous) transfers to peripherals, without software bitbanging.

author: Scrts
author_rank: Frequent Contributor
timestamp: February 04, 2015, 10:36:23 am
content: I've tried Atmel SAMA5 microprocessor memory interface to the FPGA. Works good and it's highly customizable, which makes FPGA side development really easy.

author: tymm
author_rank: Contributor
timestamp: February 05, 2015, 03:58:12 am
content: Quote from: andersm on February 04, 2015, 08:48:45 amsure. but like i said, it gets more complicated... not insanely so, but you need to dig through and match the DMA approach with the register(s) available (and for example can require 2 DMA channels & kill atomicity if you need to access separate set/reset registers).The low-end ST parts for example have a register that will let you do bit sets & resets as an atomic operation across arbitrary pins on a port, but to use it properly with DMA you'd need to precompute 32 bits per transfer rather than the 16 that you would otherwise write directly to the ODR. Not a hard thing to do at all - just takes an extra XOR per value & larger data type - but it does make for a more complicated setup - and even small amounts of data munging in some cases can even break throughput requirements.That NXP approach IIRC is basically bit banding, except it's in the address space of the peripheral. I seem to recall NXP also doing some things in that GPIO implementation - at least if it's the same one they used on the LPC11U24 - that made writing decent, low-latency GPIO abstractions a real pain... (ugliness from throwing together assorted registers from multiple GPIO ports into a single block)

author: andersm
author_rank: Super Contributor
timestamp: February 05, 2015, 07:21:13 am
content: Quote from: tymm on February 05, 2015, 03:58:12 amYou don't even need the XOR. If the same bit is set in both the "set" and "reset" halves, the pin is set, so you can treat the "reset" as a constant bitmask which can be prefilled in your transfer array.

author: knik
author_rank: Newbie
timestamp: February 05, 2015, 08:59:46 am
content: Quote from: Yansi on February 04, 2015, 09:04:31 amNo, that's not true.C-M3 is Harvard architecture, single address space, separate buses.Some time ago I did some tests on STM32F1 and by surprise code run from sram was slower than run from flash, apparently Harvard.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: February 05, 2015, 10:39:38 am
content: Quote from: knik on February 05, 2015, 08:59:46 amNo, on Cortex the memory architecture is definitely von Neumann. The fact you can execute code in "data" RAM demonstrates that (since that is the definition of von Neumann!)The fact there are multiple buses to improve performance does not mean it is Harvard, because it would work exactly the same with one bus. Only if multiple buses are *required* does it mean the architecture is Harvard, IOW if you can't execute code in Data RAM.

author: knik
author_rank: Newbie
timestamp: February 05, 2015, 06:11:47 pm
content: Can you please give more details on your definition of von Neumann architecture.What I could find clearly indicates C-M3 is not a von Neumann.ARM infocenter states:http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka11516.htmlQuoteEdit:Just found another quote from ARM:Quote

author: dannyf
author_rank: Super Contributor
timestamp: February 05, 2015, 06:14:25 pm
content: QuoteMaybe it is both?

author: rsjsouza
author_rank: Super Contributor
timestamp: February 05, 2015, 06:42:49 pm
content: In some DSPs I used to call it "modified harvard", as the core itself has multiple buses (to prevent bus contention) and the memory used to have dual port access (to allow code and data to be fetched/stored simultaneously). However, the memory space is unified (von Neumann) as you don't have code/data pages.

author: Hypernova
author_rank: Unknown
timestamp: February 06, 2015, 08:51:58 am
content: Quote from: rsjsouza on February 05, 2015, 06:42:49 pmBut sometimes the bus's can still be setup to encourage you to treat it as pure harvard. On the F28335 DSP (C2000 core) I use at work instruction fetches from the 2nd half of RAM incurs a 1-wait state penalty, vice-versa for data fetches from the 1st half.To stay on the subject of DMAs annoyingly the C2000 DMA bus have no access to GPIO DAT/SET/CLR registers. Last month when I had to do some pattern generation on GPIO pins I ended up commandeering the Ext. Memory interface output register as my data destination and using EMIF's dedicated data pins instead.

author: knik
author_rank: Newbie
timestamp: February 06, 2015, 09:42:27 am
content: Quote from: HypernovaI suppose that was it in my example.I ran the same code from ram and from flash(2 wait states) and the ram version was slower(single bus).When run from the slower flash mem it was faster(double bus).

author: splin
author_rank: Frequent Contributor
timestamp: February 06, 2015, 04:55:20 pm
content: Table 2 from the ST application note AN4566, 'Extending the DAC performance of STM32 microcontrollers' is interesting. It summarises the DMA rates writing from memory to the DAC which is on the APB1 bus. I don't know about DMA to the GPIOs specifically but this should be a good start:ProductAPB max speedDAC max sampling rateSTM32F0 series48 MHz4.8MspsSTM32F100xx24 MHz2.4MspsSTM32F101xxSTM32F103xxSTM32F105xxSTM32F107xx36 MHz4.5MspsSTM32F2 series30 MHz7.5MspsSTM32F3 series36 MHz4.5MspsSTM32F40xSTM32F41x42 MHz10.5MspsSTM32F42x45 MHz11.25MspsSTM32L0series32 MHz4.0MspsSTM32L1series32 MHz3.2Msps

author: Rasz
author_rank: Super Contributor
timestamp: February 06, 2015, 08:07:29 pm
content: Quote from: splin on February 06, 2015, 04:55:20 pmAPB2 is 2x the speedI found thishttp://forums.leaflabs.com/topic.php?id=774#post-4683" about 6.7MHz"

author: dannyf
author_rank: Super Contributor
timestamp: February 06, 2015, 10:17:13 pm
content: QuoteIt is generally available on chips equiped with DMA.

author: rsjsouza
author_rank: Super Contributor
timestamp: February 08, 2015, 07:20:52 pm
content: Quote from: Hypernova on February 06, 2015, 08:51:58 amYes, you are correct for the C28x family. I should have been clearer when I replied; I had in mind other DSP families such as C54x and C55x.Quote from: Hypernova on February 06, 2015, 08:51:58 amYes, I have heard that is quite an annoying limitation of the C28x DMA. It was also a limitation on C54x and C55x.