Announcement

Collapse
No announcement yet.

inter-processor communications

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • inter-processor communications

    Haven't made too many posts, hope this is in the right place.

    My product line revolves around 18F2520 & 2620 (more mem.) processors.

    Recently a client of mine has asked me to include wifi capabilities to some of my products. I purchased the microchip wifi com demo bd which has a 32mx695f512h processor.

    I am planning on using the mssp hardware (in each cpu) with an i2c master on the comm bd and an i2c slave on my 2520 bd. I plan on setting up 2 100-element byte arrays, 1 in each processor and exchanging all 100 bytes when either sending from the host or reading from the slave. i need to take advantage of the hardware interrupt capability of the mssp in each cpu as they are doing other things, that simple polling would interfere with.

    Question, does anyone think that SPI would be better to use than i2c? why? any better ideas? and does anyone think that i need to include crc (8 bit) error checking to the payloads? I am thinking not due to the ACK after each byte of the transfer and the physical proximity of both processors to each other, so actual signal trace lengths will be quite short.

    Any thoughts would be most appreciated.
    thanks, jack

  • #2
    Hi Jack,

    Only my opinion, but I prefer SPI. I'm more comfortable with it, and I like that there are separate out and in lines. I don't mind needing a chip select pin for each SPI device connected to it.

    The biggest thing, in my understanding, is that SPI can go a LOT faster than I2C. I have an application where the main uC is an 18F47J13. It is the SPI master and communicates with and controls up to sixteen "satellite" boards, each with an 18F27J13. Running the PICs at 48 MHz, all the boards have plenty of cycles to do their real work. It is just like having 16 completely independent processes.

    The final thing is that I can get the hardware SPI stuff to work fairly easily but I don't think I've ever gotten the hardware I2C going. When I use I2C parts I just use the PBP functions, fiddle around with it until it works well enough, and move on. So that's my own limitation and not PBP's.

    Anyway, I think you came to the right place and are heading in the right direction. I2C vs SPI, I say use the one you are most comfortable unless speed is a big issue.

    Right, CRC. I've never deliberately implemented it. I tend to keep my PIC-to-PIC communications short. I sometimes implement a simple checksum, but have been neglecting it even then because (ignoring design errors and problems caused by my soldering) I've NEVER seen a bad byte transferred. It seems that the communications either work with 100% reliability or they don't work at all. Only in wireless communications have I seen truly garbled messages. Just my two cents.

    Best Regards,
    Paul

    Comment


    • #3
      Hi Paul,

      Your input is most appreciated. You confirmed what i thought concerning error checking. I agree, in that with such short interconnect lines it is either going to work or not.

      as far as spi or i2c, i am leaning towards i2c for the simple reason that i only need 2 i/o to implement it, and on my 18f processors i/o is at a premium. Only transferring about 100 bytes on demand, so i don't think that speed is a necessity.

      The verdict is still out though, thanks for the response.

      Jack

      Comment

      Working...
      X