Looking for Cortex-M3 or M4 with DMA to GPIO capability

[poorchava]

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 array

Now 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.

[BravoV]

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 :

The <TI new Cortex™-M4F> microcontroller includes a Direct Memory Access (DMA) controller, known as micro-DMA (uDMA). The uDMA controller provides a way to offload data transfer tasks from the Cortex™-M4F processor, allowing for more efficient use of the processor and the available bus bandwidth. The uDMA controller can perform transfers between memory and peripherals. It has dedicated channels for each supported on-chip module and can be programmed to automatically perform transfers between peripherals and memory as the peripheral is ready to transfer more data.

The uDMA controller provides the following features:

* ARM® PrimeCell® 32-channel configurable µDMA controller
* Support for memory-to-memory, memory-to-peripheral, and peripheral-to-memory in multiple transfer modes
 – Basic for simple transfer scenarios
 – Ping-pong for continuous data flow
 – Scatter-gather for a programmable list of up to 256 arbitrary transfers initiated from a single request
* Highly flexible and configurable channel operation
 – Independently configured and operated channels
 – Dedicated channels for supported on-chip modules
 – Flexible channel assignments
 – One channel each for receive and transmit path for bidirectional modules
 – Dedicated channel for software-initiated transfers
 – Per-channel configurable priority scheme
 – Optional software-initiated requests for any channel
* Two levels of priority
* Design optimizations for improved bus access performance between µDMA controller and the processor core
 – µDMA controller access is subordinate to core access
 – RAM striping
 – Peripheral bus segmentation
* Data sizes of 8, 16, and 32 bits
* Transfer size is programmable in binary steps from 1 to 1024
* Source and destination address increment size of byte, half-word, word, or no increment

From the DMA API documentation :

The microDMA (uDMA) API provides functions to configure the Stellaris uDMA (Direct Memory Access) controller. The uDMA controller is designed to work with the the ARM Cortex-M3 processor and provides an  efficient and low-overhead means of transferring blocks of data in the system.

The uDMA controller has the following features:

* dedicated channels for supported peripherals
* one channel each for receive and transmit for devices with receive and transmit paths
* dedicated channel for software initiated data transfers
* channels can be independently configured and operated
* an arbitration scheme that is configurable per channel
* two levels of priority
* subordinate to Cortex-M3 processor bus usage
* data sizes of 8, 16, or 32 bits
* address increment of byte, half-word, word, or none
* maskable device requests
* optional software initiated transfers on any channel
* interrupt on transfer completion

The uDMA controller supports several different transfer modes, allowing for complex transfer schemes. The following transfer modes are provided:

* Basic mode performs a simple transfer when request is asserted by a device. This is appropriate to use with peripherals where the peripheral asserts the request line whenever data should be transferred. The transfer will stop if request is de-asserted, even if the transfer is not complete.

* Auto-request mode performs a simple transfer that is started by a request, but will always complete the entire transfer, even if request is de-asserted. This is appropriate to use with software initiated transfers.

* Ping-Pong mode is used to transfer data to or from two buffers, switching from one buffer to the other as each buffer fills. This mode is appropriate to use with peripherals as a way to ensure a continuous flow of data to or from the peripheral. However, it is more complex to set up and requires code to manage the ping-pong buffers in the interrupt handler.

* Memory scatter/gather mode is a complex mode that provides a way to set up a list of transfer “tasks” for the uDMA controller. Blocks of data can be transferred to and from arbitrary locations in memory.

* Peripheral scatter/gather mode is similar to memory scatter/gather mode except that it is controlled by a peripheral request.

[Memphis]

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.

[nctnico]

I'd use the ethernet MAC. You simply dump data into it without any protocol.

[andyturk]

Now the problem is, that GPIO<->DMA transfers seem to be largely omitted by chip manufacturers. [...] On top of that I'm kind of biased towards STM32 family.

I'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).

[mikeselectricstuff]

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

[jmole]

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 called freeSoC, and Cypress recently announced a low-cost PSoC 4 board (same digital flexibility, but a slower proc) called PSoC Pioneer.

[westfw]

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.

Wouldn't that be the default assumption, for an architecture with a single address space?

[poorchava]

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?).

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.

That 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

[Memphis]

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?).

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.

That 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

The 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. 

[knik]

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.

[andersm]

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.

Does 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.

[poorchava]

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.

[free_electron]

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

That's the way i do it. Get a cpu with the EMIF ( external memory interface) exposed ( typically those are the vety high pincount beasts)

[nctnico]

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.

[westfw]

the ethernet MAC is the best way to go.

Is 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?

[knik]

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.

Does 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.

To 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.

[saigai]

Now 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.

I 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)

[Rasz]

http://www.arrownac.com/manufacturers/stmicroelectronics/stm32-primer/appnote.pdf

https://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=660

https://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=102



stm32F103 should do it with no problem

btw Stmicro forum is soo garbage :/

[0xdeadbeef]

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.
Also my little engine signal generator makes heavy use of DMA.

[tymm]

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.

[andersm]

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.

Most, 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.

[miceuz]

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

[Yansi]

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 array

Now 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.

Regarding 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.

[Scrts]

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.

[tymm]

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.

Most, 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.

sure.  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)

[andersm]

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.

You 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.

[knik]

Regarding that ARM is Von Neumann architecture, so it has only one memory space and memory mapped peripherals

No, 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.

[donotdespisethesnake]

Regarding that ARM is Von Neumann architecture, so it has only one memory space and memory mapped peripherals

No, 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.

No, 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.

[knik]

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.html

QUESTION
What is the difference between Harvard Architecture and von Neumann Architecture?
ANSWER
The name Harvard Architecture comes from the Harvard Mark I relay-based computer. The most obvious characteristic of the Harvard Architecture is that it has physically separate signals and storage for code and data memory. It is possible to access program memory and data memory simultaneously. Typically, code (or program) memory is read-only and data memory is read-write. Therefore, it is impossible for program contents to be modified by the program itself.
The von Neumann Architecture is named after the mathematician and early computer scientist John von Neumann. von Neumann machines have shared signals and memory for code and data. Thus, the program can be easily modified by itself since it is stored in read-write memory.

Edit:
Just found another quote from ARM:

http://www.arm.com/files/pdf/IntroToCortex-M3.pdf:
At the heart of the Cortex-M3 processor is an advanced 3-stage pipeline core, based on the Harvard architecture,

[dannyf]

on Cortex the memory architecture is definitely von Neumann.

Maybe it is both?

[rsjsouza]

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.

[Hypernova]

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.

But 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.

[knik]

But sometimes the bus's can still be setup to encourage you to treat it as pure harvard

I 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).

[splin]

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:

Product

APB max speed

DAC max sampling rate

STM32F0 series

48 MHz

4.8Msps

STM32F100xx

24 MHz

2.4Msps

STM32F101xx STM32F103xx STM32F105xx STM32F107xx

36 MHz

4.5Msps

STM32F2 series

30 MHz

7.5Msps

STM32F3 series

36 MHz

4.5Msps

STM32F40x STM32F41x

42 MHz

10.5Msps

STM32F42x

45 MHz

11.25Msps

STM32L0

series

32 MHz

4.0Msps

STM32L1

series

32 MHz

3.2Msps

[Rasz]

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

 APB2 is 2x the speed
I found this
http://forums.leaflabs.com/topic.php?id=774#post-4683

" about 6.7MHz"

[dannyf]

Now the problem is, that GPIO<->DMA transfers seem to be largely omitted by chip manufacturers.

It is generally available on chips equiped with DMA.

[rsjsouza]

But 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.

Yes, 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.

To stay on the subject of DMAs annoyingly the C2000 DMA bus have no access to GPIO DAT/SET/CLR registers.

Yes, I have heard  that is quite an annoying limitation of the C28x DMA. It was also a limitation on C54x and C55x.