SPI communication between two MCUs on same board

[nctnico]

SPI isn't any more susceptible to interference than any other CMOS push-pull communication link. If SPI fails, external RAM or flash fails as well. Yet nctnico is fine using external RAM or FLASH, but not fine using SPI. This is highly illogical (and discussed to death already).

External RAM and flash are not synchronous like SPI and usually RAM & flash are very close to the processor so interference is unlikely. Remember a false pulse on the SPI clock line means a state change! If you are going to route SPI over a board for 10 cm or more you can run into trouble. Especially with high power components nearby (even on 4 layers boards with a solid ground plane). I'm not pulling this out of my ass; this is hands on experience talking. You can keep yabbering on about signal integrity but the fact is that SPI is more prone to problems over long traces compared to I2C.

If you compare to I2C you'll see the electrical interface of I2C has been specifically designed to filter out spikes and offer a large noise margin. As a result you can run an I2C bus over tens of cm on a single layer board inside a CRT TV without problems. I2C is not a simple push-pull communication link, it has been cleverly designed to have a low susceptibility against noise / interference. The same goes for UARTs. These also have been designed to deal with transmission in noisy environments.

[NorthGuy]

I was using the FreeRTOS +TCP stack, and was seeing around 10Mbit/s RX and 18Mbit/s TX using iPerf; these figures were corroborated by other FreeRTOS users on this platform. There is definitely room to optimise further, but as has been stated earlier, the use of the full TCP/IP stack is complete overkill for a (largely) unidirectional, point to point channel.

Look for a bottleneck. Data transmission is always a chain of events. Find the event which is the slowest. Such event will hold the whole chain and will limit the speed of the whole transmission.

There could be a software bottleneck (some part of the software is too slow), or hardware bottleneck (e.g. a controller is too slow).

[jars121]

Thanks all for your input.

Signal integrity has been raised a number of times now, which is a valid concern. I have other SPI interfaces in use elsewhere on the board, which have been tested at 50MHz with no issues. I don't expect there to be any issues with signal integrity if I were to use SPI for this particular interface, as I'll pay the same very close attention to routing and ensuring all best-practise SI considerations are followed.

Having said that, I've done some further reading overnight, and am investigating the raw ethernet frame approach a little more closely. Both PHYs support auto-negotiation by default, so a 100BASE-TX full-duplex link should automatically be established. This should mean I don't need a PHY driver, but it has been suggested it might still be a good idea to have a light-weight PHY driver to monitor the link status, to know when the link has been established, etc.

I'm still not entirely clear on the driver for the raw ethernet frame. I suppose I can start with the TCP/IP stack I already have, that currently works, and work backwards from the point of data being sent out on the wire.