Selecting the best/fastest communication method CPU->CPU

[stefanskos9]

Posted on February 11, 2013 at 01:30

Hi All,

I'm making a PCB that has two STM32F4 DSP chips across an isolation barrier. I need the two chips to communicate as fast as possible, with the one chip (slave) passing new values to the other chip's (master's) EEPROM. There will hopefully be quite a few values updated every every ~10uS. Data integrity is important too as the values cant become corrupt and i don't want to spent lots of CPU time error checking the incoming values. The master chip will send back misc data for logging which is less important. I'd like the received values on the master to go straight to DMA. An ack of the data is probably a good thing too incase it needs to be sent again. It seems USART is the quickest comm method on the STM32F4, but is this recommended considering I need data integrity? What about I2C or CAN? One of the parallel interfaces? I want the send and recieve to take up as little CPU time as possible as other code will be running simultaneously with lots of time sensitive interrupts. Reminder, all communications need to cross an isolation barrier - though i think this should effect all methods equally. Thanks for your help / suggestions! :)

[Tesla DeLorean]

Posted on February 11, 2013 at 02:07

16-bit word SPI?

[emalund]

Posted on February 11, 2013 at 03:46

It seems USART is the quickest comm method on the STM32F4, but is this recommended considering I need data integrity? What about I2C or CAN? One of the parallel interfaces?

there will be no ''data integrity'' issues because of using the UART, I²C, SPI, CAN, .... with solid hardware ''data integrity'' is not an issue with either. select the method based on your other concerns Erik PS Just a thought 'isolation' and several bytes in 10us? most isolation I have seen is too slow for this, what are you using?

[jj2]

Posted on February 11, 2013 at 05:06

Such barriers are cost & size sensitive - based upon channel number.  This argues against the fastest - clearly parallel w/strobe. 

Thus Clive1's input of SPI moves ''front/center.''  If I was doing this - I'd ''bypass'' the isolation during development - insure that both sides are well behaved and robust - and only then add (and monitor) the performance thru the barrier. You do realize that saving to EEprom will greatly reduce your transfer speeds - you should probably do this in bulk - after transfers go reasonably quiet...

[stefanskos9]

Posted on February 11, 2013 at 06:51

Just a thought 'isolation' and several bytes in 10us? most isolation I have seen is too slow for this, what are you using?

Some of the RD digital isolators can be pretty fast. The below 6ch can operate upto 150Mbps for example. https://www.silabs.com/Support%20Documents/TechnicalDocs/Si846x.pdf16-bit word SPI?Thus Clive1's input of SPI moves ''front/center.'' So you and Clive are saying the SPI is my best bet?You do realize that saving to EEprom will greatly reduce your transfer speeds - you should probably do this in bulk - after transfers go reasonably quiet... Yeh thanks. Not all values will have to update the EEPROM, most will just be stored in RAM/flash as they will be overwritten again shortly. For these values, i'd be great if the data could have some identifier and update the appropriate value through DMA. Otherwise i guess i may just have to store in a buffer through DMA and then process the data when I have some spare CPU time. Can all the communication methods utilise DMA?

[flyer31]

Posted on February 11, 2013 at 07:33

SPI will be only really fast in such an isolated interface, if your data stream goes only from (clock generating) master to slave. The problem with these hi-speed digital isolators is, that they can introduce some delay which is very appreciable in such hi-speed interfacing apps - so if the clock goes in one direction, and data opposite, it will not work.

So you would have to take either SPI master to slave, or UART (no clock, very nice), or parallel - I assum parallel of course would be the fastest. Just EEPROM is an extremely slow storage device - so you will need a large FIFO buffer in front of your EEPROM... .

[Tesla DeLorean]

Posted on February 11, 2013 at 13:29

I've seen these use on a JTAG interface, which is basically a very long SPI type scan chain, ie clocking out data, clocking back the returning data.

http://www.analog.com/static/imported-files/data_sheets/ADuM1400_1401_1402.pdf

You'll have to evaluate the maximum bandwidth, and if it is useable. DMA could be used for long runs of data, probably circular with a few dozen bytes or more. Data streamed back and forth with a SLIP type protocol, stuffing when no data ready. Parallel will buy you more bits/speed, but will make any slewing in the interface more difficult to address. It's been suggested DCMI could be use for parallel data, but that's going to be a unidirectional interface.

[hrobinson]

Posted on February 15, 2013 at 18:11

EEPROM is slow - have you thought of using FRAM?  Write cycle takes no time at all.  I just implemented one, drop in replacement for the EEPROM I was using, works a treat.  Only slight downside for speed, it's 8-bit transfers, marginally slower than 16 bit on SPI.  But still very fast overall process.