Fastest communication interface between two STM32F7's

[Maz D]

Posted on July 31, 2017 at 16:02

Hi,

I have a simple question but which causes me a little headache.

Does anyone know how I might interface two STM32F7 so that I might obtain the fastest communication between the two?

Something better than 10MBytes would be the best and 20MBytes excellent.

If my question needs more info do not hesitate to ask for clarification.

All help would be appreciated.

Thanks

#speed #interface #best #fastest #communication #stm32f7

[William Warnots]

Posted on August 03, 2017 at 09:58

Use SPI with  Chip select software , but you need remember that set the pin frequency very High.

[Maz D]

Posted on August 03, 2017 at 09:54

I might be wrong on this, but for me there is no QSPI slave on the STM32F7. There is also the issue with the clock pin and clock synchronisation.

That said I am ready to do some engineering to get it to work if you have further technical details on how I might get it done?

[T J]

Posted on August 03, 2017 at 09:59

I am working with a F767 in cube and visual studio,

I checked the cube, the only DMA function for QSPI seems to be a Slave Receiver.

[Eugene Solo]

Posted on August 03, 2017 at 10:10

well, yes, that might be a problem with simple direct approach. QSPI module is meant to be bus master. Same as SD/MMC, ethernet, etc.,etc. But if you can put one chip in the middle (as it was mentioned, FPGA), QSPI will be simplest in terms of implementation (less wires, strictly synchronous, simple glue logic in FPGA).

Without any glue logic and relatively fast will be something like I2S (not I2C!).

Or, probably, just SPI, but few channels working simoultaneously (one channel transmits one part of data, another channel - next part of data, etc. DMA should help to increase bandwidth)

[David Littell]

Posted on August 03, 2017 at 13:55

Re setting the pin frequency very high: not necessarily.  An understanding of the signal's load capacitance and the actual operating frequency is needed.  Look for the I/O AC characteristics table in the Data Sheet, scope it while operating, and use the lowest workable setting.

[Ken Coley]

Posted on August 03, 2017 at 16:45

You didn't mention if the two STM32F7 were on the same PCB or different ones.  Ethernet would be the simplest for multi-board since not only is the hardware well defined, but the software stack is also.  If the MCUs are both on the same board then you might want to look at a shared memory block implementation or as many above mentioned an SPI solution.  Without knowing more about the application and data flows, its hard to recommend a specific implementation.

[Maz D]

Posted on August 03, 2017 at 18:16

Yeap they are on the same PCB.

[Willem La Grange]

Posted on August 03, 2017 at 23:03

I would use a USB HS device to USB HS Host (or OTG is also possible) as the fastest communication medium (480Mb/s) and you have DMA  with shared memory to speed things up even more. Use the external PHY for best results but it is not cheap. That would be the easiest firmware solution as well. 

The problem is the decoding and action on these message with a clock speed od only 216MHz. I agree that you should rethink why do you need that speed! Maybe it would be better to wait until October 2017 for the H7 series to launch at 400MHz.

Using Dual port RAM and the FMC will also give you pretty good speeds but there has to me something more to signal start and end of messages. Will be easy to loose sync if used as a communication medium.

[Daniel Glasser]

Posted on August 03, 2017 at 22:24

I've not done this with STM32 (for one, I'm a SW engineer, and I deal with what the HW folks give me), but I have done software for boards with an RGMII to RGMII connection between two parts.  If I recall correctly, the ref-clock fed into each side were something like 90 or 180 degrees out of phase of eachother for some reason (probably found in an app note).

The design had a pair of PPC440GXs connected via RGMII, not STM32F7xx over RMII, but I suspect the same can be made to work; the trick is that each side will think the other side is a PHY, and doesn't know that the other side thinks that it's a PHY, so some changes to the low-level SW might be needed.  It's been too long for me to recall what changes were needed in the SW on that project.

Edit: A quick google search for 'rmii to rmii' yielded an article that uses RMII between a STM32F107 and a standard (stock) MAC IP core in a Xilinx FPGA (see 

http://www.jsykora.info/2016/01/connecting-mcu-and-fpga-at-100mbits-using-ethernet-rmii-part-1/

)