What is the best way to connect multiple Stellaris Cortex-M3 microcontrollers with EPI to each other

What is the best way to connect multiple Stellaris Cortex-M3 microcontrollers with EPI to each other for high-speed interprocessor communication??

• rated by 0 users
• 1 Follower
• 0 Replies |
• This post has 0 verified answers |

• Posted by Weatherbee on 21 Mar 2010 8:33 PM

  I need opinions on the best method of accomplishing the following architectural I/O requirement:

  I am working on an application that will use up to 5 Stellaris ARM Cortex-M3 microcontrollers together in an expandable way using a backplane free mezzanine type expansion connector.  One of the microcontrollers will use RS422/RS485/Ethernet/USB to communicate with the "outside world."    This controller will act as a system "master" with up to 4 slave daughterboards each of which will be equipped with some I/O and an additional microcontrolller.  

  All of my microcontrollers have the following I/O interfaces in common: UART, CAN, SPI, I2C and EPI.

  I have a bandwidth requirement for each "slave" channel of 10Mbps full duplex (20Mbps total) - simultaneously on all 4 slave channels.

  I could accomplish this in theory if the master microcontroller had 5 or 6 UARTS but that feature is not available in any Cortex-M3 part that I have seen.  I have also looked at hooking up an external 4 port UART to the EPI but those seem to be limited to about 5Mbps at best and would probably generate an excessive amount of interrupts to sustain that rate on each channel.

  CAN is not an option because its bandwidth capability (1Mbps simplex) is totally inadequate.

  I2C doesn't even come close and SPI can't pull it off either. 

  So I seem to be left with one option: something hooked up via the EPI.  The EPI is theoretically capable of 150MB/s in "general purpose" mode (my guess is that TI calculates this using a 24-bit paralell FIFO operating and 50MHz).  By my calculations though with an external demultiplexed  x8 SRAM it can maintain a burst rate of 50MB/s (400Mbps).

  The EPI on the Stellaris MCUs *seems* to be capable of master mode only operation, if anyone understands differently (i.e. how to get it to operate as a bus slave) please let me know.  Barring that I have had a few ideas about how to meet this bandwidth requirement without excessive additional cost:

  1) Add a small Dual-Port x8 SRAM to each slave card along with the necessary chip select logic allowing the master and slave CPUs to write to the dual-port asynchronously and in a random nature.  On the upside this maximizes bandwidth, provides a memory-mapped DMA like access to the slave data and has an efficient random access nature (i.e. if the slave is generating a lot of data but the master only needs to read a bit of it).   Downsides are that dual-port SRAMs appear to be expensive (judging from the costs of IDT and Cypress parts) and the parallel bus requires a large number of pins to be routed on the mezzanine.  It also *seems* kind of old school with everyone these days preferring serial buses in embedded systems.

  2) Add an inexpensive (grin) FPGA next to each microcontroller.  Communicate with the FPGA via the EPI and have the FPGA communicate with the other FPGAs over some sort of bidirectional synchronous serial interface.  The main controller's FPGA would implement 4 such synchronous serial interfaces. Banked RAM in the FPGAs would provide buffer space and random access to data.  Upsides are flexibility and an easier bus debug (once you get it running).  Downsides are cost, complexity, design time, the need to roll your own protocol/memory arbitration scheme, etc. 

  3) Use some kind of RapidIO style switched fabric communications technique perhaps resident to an FPGA attached via the EPI or a standalone transceiver.   Upsides are that is what RapidIO is made for (interprocessor communication in embedded systems), future compatibility and the bandwidth is more than enough.   Downsides are (1) I haven't been able to find a standalone RapidIO transceiver that would work with an old-school bus like the EPI (2) anything and everything equipped with RapidIO is expensive (3) even if I could do it it would be overkill by a factor of about 50 and (5) I don't exactly have the tools to debug a serial interface that operates in the GHz.

  4) Something involving a standalone FireWire transceiver but I know next to nothing about that and they are probably expensive and designed to talk to a PCI bus.