Computing > Embedded Computing

ARM with fast parallel GPIO

<< < (9/10) > >>


--- Quote from: Berni on June 17, 2021, 09:20:22 am ---The SDRAM pins usually don't really have any special IO drivers on MCUs, they just set the IO for the highest drive strength.

--- End quote ---

Possibly so, although I do not know that for sure on all MCUs.

But that's beyond the point - what matters is, SDRAM controllers can usually get you faster data throughput than using any other peripheral on most MCUs. As I mentioned, what mid-range MCU using what peripheral  can get you a parallel bus @166MHz? I do not know of many examples. That was the point.

Of course if on some MCU, you have an FMC-like interface that can work at the same frequencies, it's much easier to use that. But I just haven't seen many MCUs like that.

True the SDRAM interface is typically the highest clocked. But it does have significant amount of overhead and latency where it has to set up a transaction before it happens so there are some slight tradeoffs still.

The kind of interface that is really well suited are synchronous SRAM with burst transfer support. This is used by some parallel interface raw flash chips.It looks similar to SRAM except it does have a clock and the burst transfer will transfer a word of data on each clock cycle. This also typically optionally supports address latch mode so the first word of the transfer contains the address, saving you a lot of address lines.

Still the sort of speeds possible with these are so high that a MCU might have difficulties doing something useful with it, since at that point the CPU only has 1 or 2 instruction cycles per word for doing any actuall processing on it. So for this reason a high clocked QSPI tends to be as fast as you would typically need to go. Most of the benefit for using a external memory bus is that the FPGA can be memory mapped to the CPU like any other peripheral. This potentially saves a significant amount of overhead inside peripheral drivers that otherwise need to be told to actually send a command over that does the thing you want to do, yet if its memory mapped the CPU can work with it just like the FPGA was built into the same chip. No need to DMA buffers over into RAM to be worked on, you can just access the buffer like it is RAM itself.

For 4-bits, Quad SPI can be used.  However, for more bits, it gets tricky.

A solution I have seen before used an inexpensive CPLD, which took SPI data and derived a 1/8th clock from the byte data to do serial to parallel conversion.    In principle if you keep the SPI buffer fed the data will be continuous. The trick then comes in doing it at high data rates - SPI might max out around 25Mbit/s, so max 8-bit data rate ~3.12MHz.  You could try a quad-SPI to 8-bit converter, which would get you up to 12MHz.  Still quite below your 50-100MHz goal.

There exist some ARM+FPGA devices, though probably overkill for this.   A lightweight option of a Microsemi SmartFusion SoC is an option, but the toolchain is bloody terrible, and the device isn't exactly cheap.  Xilinx Zynq is almost certainly overkill, but this kind of work is its bread and butter (software/FPGA fusion)

A CPLD or micro FPGA with an integrated PLL might be able to take jittery 8-bit parallel data and clean it up somewhat - feed in the data with some handshaking signals and you could get a decent buffer rate out.  But you'd probably need to buffer hundreds of samples to clean the jitter up nice enough and the FPGA design would not necessarily be trivial if you haven't done that kind of thing before.


--- Quote from: Berni on June 17, 2021, 07:09:37 pm ---True the SDRAM interface is typically the highest clocked. But it does have significant amount of overhead and latency where it has to set up a transaction before it happens so there are some slight tradeoffs still.

--- End quote ---

Yes, it's far from ideal. I was just somehow getting technix's point.

Generally speaking, I find easy-to-use, general-purpose, high-speed interfaces lacking on MCUs in general.
Your best bet for high-speed/low pin count are ethernet (but it's rarely gigabit ethernet on MCUs, which would still be "only" about 100 MBytes/s, and 100M ethernet is 1/10th that...) and USB. Both are relatively annoying to implement on the other side, except if the device you want to communicate with already supports this.

Could be nice to have some high-speed SERDES on common MCUs, say Cortex-M7, that could be used for general-purpose stuff, without too much overhead and a not too complex protocol to handle. And preferably one that is not covered by a nasty patent with fees to pays to use it. Anyway...

Otherwise, of course, one approach is to use a FPGA. Either connected to a MCU - as said by tom66, comm between the two can be asynchronous, and the FPGA can take care of making it synchronous. Or, you can do it all on FPGA with a soft core.

I seen cases where people used the SPI peripheral as "SERDES" on a 8bit AVR in order to get fast enough IO to bitbang color composite video out of it. Tho on these small 8bit MCUs the SPI runs at the same clock speed as the CPU. On a more modern ARM chip the SPI typically runs significantly slower on its own peripheral bus, so its not nearly as useful of a trick. Still QSPI is not to be underestimated in terms of speed.

In my projects i always used a SRAM bus to get high bandwidth communication between a MCU and FPGA and it works great (Especially love being able to debug FPGA peripherals straight from the MCU IDE since its all just memory). Or if speed was not as critical, then a SPI bus that encodes  bus read/write commands.


[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Go to full version