Remove Text Formatting
Loading...

+ Reply to Thread
Results 1 to 9 of 9
  1. #1
    Join Date
    Apr 2014
    Posts
    63

    Default Communications Protocol Choices

    I'm a bit new to communications between processors. I recently spent the time to get USART (HSERIN/HSEROUT) functional. It seems this is a great communications protocol for 2 processors to talk to each other. I'm developing a controller that will incorporate several processors, each dedicated to specific functions. I want them all to be able to talk to a Host (PIC18F25K50) that can then talk to a laptop via USB.

    I looked at SPI and I2C. SPI seems hardware intensive, whereas each processor would require a Slave Select (SS) pin. I2C only needs 2 pins (SCK/SDA), but seem software intensive.

    Has anyone wired several processors together? Which protocol did you choose, and why?

  2. #2
    Join Date
    May 2013
    Location
    australia
    Posts
    1,203

    Default Re: Communications Protocol Choices

    thats a pretty big subject , I would be thinking along these lines

    the physical layer depends on :-
    transfer rate is it megabytes/S or bits/S
    transfer distance is it kilometers or millimeters
    transfer cost [priority,interrrupts,reliability,latency]
    is it a master slave or a multi master or peer to peer network
    does the physical layer need collision sense , ack/nak ,crc
    the protocol layer depends on :-
    is it just master multi slave or will it need multi master or peer to peer comms
    does it need ack/nak ,crc
    is it a compelled sequence or asyncronous system
    will the slaves be polled or do they need separate channel/s to signal master
    when they have the need
    This is more entertaining than Free to Air TV

  3. #3
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,131

    Default Re: Communications Protocol Choices

    As Richard says, as is usually the case, it depends.... :-)

    If there are severeal boards connected together within the same enclosure like thru a backplane connector etc then you could possibly use the open drain UART aproach (bus pulled up by a resistor and each device yanks it low) for the physical layer - then you apply a PROTOCOL (ie the "language" the devices uses to speak to each other).

    If the boards are spread out I'd probably look at RS485 as the physical layer, either half or full duplex depending on what you're doing. Same thing again, you apply whatever protocol you want and transfer it via RS485.

    A protocol can be as easy or as complicated as you want/need to make it. MODBUS is a fairly common master/slave protocol for industrial stuff but it might not suit YOUR needs at all.

    CAN is another option, which is a differential bus (like RS485) with a specified protocol but the complexity increases.

    /Henrik.

  4. #4
    Join Date
    Apr 2014
    Posts
    63

    Default Re: Communications Protocol Choices

    Thanks for the responses. Individual MCUs will be mounted on the same board, same plane, with one exception. One of the MCUs will be located perhaps 1-3 meters (several feet) away from the Master Controller, and be routed through a somewhat electrically noisy environment.

    I'm intending for a single Master with all other MCUs configured as polled Slaves.

    The I2C protocol seems like it's suitable so far. I'm just unclear on how much "work" is done manually with software and how much occurs in the background with hardware. The PBP3 Manual lists I2CREAD/WRITE commands, but states they are software driven and don't rely on I2C hardware.

  5. #5
    Join Date
    May 2013
    Location
    australia
    Posts
    1,203

    Default Re: Communications Protocol Choices

    i2c would be my last choice , pbp has no slave implementation, no hardware implementation

    spi is easy and fast uses hardware but not brilliant at several metres in noise
    but then again pbp has no built in functionality for spi modules

    rs232/tty ,rs485 are good at distance and noise and use the hardware modules , a little slow

    you make no mention of transfer speeds , frequency or data size
    This is more entertaining than Free to Air TV

  6. #6
    Join Date
    Mar 2003
    Location
    Commerce Michigan USA
    Posts
    1,017

    Default Re: Communications Protocol Choices

    For good noise immunity I would suggest RS-485 for any distance. I use a protocol which is loosely based on Modbus RTU.
    Dave Purola,
    N8NTA
    EN82fn

  7. #7
    Join Date
    Apr 2014
    Posts
    63

    Default Re: Communications Protocol Choices

    Quote Originally Posted by richard View Post
    i2c would be my last choice , pbp has no slave implementation, no hardware implementation

    you make no mention of transfer speeds , frequency or data size
    As for transfer speeds, I intend to use a Rotation variable in the Master that polls one peripheral MCU each pass of the Main loop. Transfer size is 2 bytes; first byte is what the data is (Temp) while the second is the value of that variable (71).

  8. #8
    Join Date
    Mar 2003
    Location
    Commerce Michigan USA
    Posts
    1,017

    Default Re: Communications Protocol Choices

    Here is something I found quite a while ago. Use it as a starting point...
    Attached Files Attached Files
    Dave Purola,
    N8NTA
    EN82fn

  9. #9
    Join Date
    Apr 2014
    Posts
    63

    Default Re: Communications Protocol Choices

    Thanks Dave, I downloaded it and will give it a thorough looking over.

Similar Threads

  1. LCD port bit choices
    By rossfree in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 3rd September 2006, 10:22
  2. RF communications
    By Ron Marcus in forum Forum Requests
    Replies: 3
    Last Post: - 3rd November 2005, 00:28
  3. OBD II Protocol
    By L_Gaminde in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 30th July 2005, 06:12
  4. Map27 Protocol
    By Darrenmac in forum mel PIC BASIC Pro
    Replies: 0
    Last Post: - 16th February 2005, 03:53
  5. Sony Protocol help
    By zazery in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 30th April 2004, 04:00

Members who have read this thread : 23

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts