1. Home
  2. Embedded Programming
  3. Inter-processor communication methods

Inter-processor communication methods

Hi everybody-

My last few projects have used multiple microcontrollers that communicate using serial transmissions (both sync and async) at high data rates (about 1-10MHz bit rate) so that each can share the load of work required on the same board.

If you have also done similar, I'm wondering what data transport and data integrity protection mechansims you have used for your inter-processor communications for your applications. I am trying to gain insight into whether or not I need to implement anything other than the simplest data transport protocol to ensure delivery (like handshaking and checksums or whatever).

In my past similar projects, the systems were using microcontrollers that are physically close to each other with serial comm trace lengths no longer than 2 inches. I implemented checksum checking on each message. I never once logged a checksum error after probably gazillions of messages. I'm wondering if non-trivial transport and data integrity and protection mechanisms might be overkill in close proximity IPC applications.

Can anyone share any useful experiences to help guide me?

Thanks, JJS

Reply to
johnspeth
Loading thread data ...

Basically checksums or CRC on the same board is something you simply do not need at the speeds you mention. All the hardware, memory interfaces etc. work at much higher speed without error correction/detection. At DDR and SDRAM speeds, sometimes there are error correction options, though you can get away without using them most of the time.

I have used a number of different techniques. One was to use two FIFO chips (remember those IDT72xx chips?), one per direction, on my almost oldest system (two 6809s talked via these, one was system the other one was graphics board at a proud 640x408 - right, 408 not 480 - resolution). Later I have used even SPI to have a host talk to a number of (small, typically hc11) slaves. This was tougher than it sounds because of the SPI nature and all the syncronization issues involved, but it did get quite practical. Later, I used a PCI 68k bridge (the so called qspan from Tundra semiconductor), now this gives you a lot more speed and flexibility. I also used a 5420 DSP, which has the two FIFO technique I talked about above implemented on chip between its two cores, works really fast. But I guess I2C is a reasonably flexible/popular interface for on-board low speed communication. Ah, I also remember now there was some fairly fast serial link which used to come with those "transputer" chips from INMOS, I did use it once around 1990... I don't know what happened to them (INMOS, that is) though, I guess they did not have the marketing muscle to push their otherwise pretty nice products.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

snipped-for-privacy@yahoo.com wrote:

Reply to
Didi

In general, if there are connectors involved you should do some kind of checksum. Either you have a good connection, in which case you shouldn't see errors, or something is seriously wrong, in which case you probably see garbage or nothing. The checksum lets you know when you're seeing garbage. It prevents the garbage from quietly causing other, completely mysterious, errors.

The main point of such error checking is to identify a problem as close to the source as possible.

For this purpose, a CRC is overkill. All you're looking for is a sanity check.

mac the naïf who has spent far too much time chasing mysterious errors

Reply to
Alex Colvin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.