Connect with us

Which multi-PIC mid-range comms protocol?

Discussion in 'Electronic Design' started by Grant, Aug 11, 2010.

Scroll to continue with content
  1. Grant

    Grant Guest

    Hi there,

    Used up all the good resources of a PIC16F886 to make a high
    resolution ADC (well, soon to be built, but gone through all
    the required PIC resource allocation), now I need to talk to
    another 16F886 (28pin) or 16F887 (40pin) PIC for RTC (32kHz
    watch xtal) and system control.

    The ADC chip already taken the EUSART for serial comms to PC
    option. That leaves the other comms module:

    Master Synchronous Serial Port (MSSP) Module
    supporting 3-wire SPI (all 4 modes) and I2C
    Master and Slave Modes with I2C Address Mask
    " -- 16F886 datasheet

    for talking to other chips and PICs.

    I'm after suggestions for which master / slave inter-chip
    protocol is easy, reliable for local (within a couple feet)
    comms. Gotchas, pointers?

    I'm programming in assembler with the MPLAB environment at this

    Thanks in anticipation,
  2. Jamie

    Jamie Guest

    MODBUS/RTU on a balanced twisted pair( 485 ) works well, the MODBUS
    supports 31 devices.. A well known protocol, why reinvent the wheel?
  3. Tauno Voipio

    Tauno Voipio Guest

    Implementing MODBUS/RTU packet timing to the specification
    is a PITA. It demands tight character-to-character timing
    and measurement of interpacket timings. This prevents using
    the built-in FIFO's in the serial chips, and the timing is
    practically impossible to implement on a PC due to the
    unpredictable interrupt latencies introduced by operating

    Been there - bit badly by that.
  4. Grant

    Grant Guest

    Not where I'm heading, more likely a tiny serial <-> usb gateway
    to PC for control and data logging, and separately SPI or IIC to
    other chips, I don't need rs485 to talk a foot or two between
    chips for this project set.

  5. Jamie

    Jamie Guest

    Oh really, we've never had any issues implementing that in small
    devices. I really don't see the problem? The master is the one
    that sends data to a specific device and also makes request for
    the device to return data. The slave device does not tx nothing
    until its asked too. And that, obviously doesn't happen until the
    request what to send it fully received in the slave. If a master
    can not get it's shit together by then, something is being done

    Oh well, have a good day!
  6. nospam

    nospam Guest

    MODBUS RTU is pretty crap and everyone puts in options to adjust the timing
    requirements or just plain ignores them.

    I implemented a master talking to a commercial HMI panel. All worked fine
    until I tested the comms were reliable by breaking and reconnecting the
    serial link.

    About 1 in 3 times it hung up with the HMI not responding and if you left
    it long enough the HMI would come up with some mal-formed error message
    that didn't make sense and that the manufacturers said they had no
    knowledge of.

    It turns out that instead of following MODBUS specifications and taking any
    silence of more than 3.5 character times (at 38k4 baud) as an indication of
    frame start it ignored silences of over 100ms and considered the retry
    packets I was sending every 100ms to be part of the same mal-formed frame
    which (I assume) it kept storing for 2-3 minutes till it ran out of memory
    and crashed. After increasing the delay between retry packets to 200ms it
    all worked fine.

    That HMI 'adjusted' the MODBUS RTU timing requirements by a factor of over
    100 with no option to change it and no documentation.
  7. Jamie

    Jamie Guest

    Strange, we use CRC in our packets. in an industrial environment, you
    have to expect some noise on the line.. a retry normally solves errors..
    if it gets so bad that you have lots of retries and CRC's are failing
    then, you really have a serious problem.. Using a balanced twisted pair
    helps. parallel tracks on PCB also help.

    Have a good day..
  8. The panel maker clearly did no understand that two different timeouts
    are required in the slave, one waiting for the first character
    (possibly infinite) and a much shorter inter character timeout for the
    rest of the message.

    Apparently the programmer had only one time out and in order to avoid
    timeouts waiting for the first character, the timeout was increased
    several times :).

    In practice, there are only a few critical timing issues with Modbus
    and they are related to slaves on 2 wire multidrop network.

    Assuming slaves X and Y are on the same 2 wire bus with a master M and
    possibly other slaves. The master communicates with slave X by sending
    the request message. Slave Y also hears the request, but since it is
    not addressed to it, it will ignore it. Then it hears an other frame
    with the X address. Slave Y does not know if it is retransmission from
    the master to X or a reply from X (since you can not always determine
    this from the syntax of the message). Anyway, slave Y ignores this
    message too.

    Slave Y must _reliably_ detect the end of that (apparently reply
    frame) from X and immediately after that be prepared to new commands,
    which might be addressed to Y.

    The standard method requires that there is at least a 3.5 character
    silent time before the master sends the next frame and that each slave
    must be able to detect such short gaps reliably. If this gap detection
    fails for one reason or other, the reply from slave X and the master
    to Y request is appended into the receiver buffer. The CRC check will
    hopefully detect that something is wrong and no reply is generated.

    Since the master did not get a response within timeout time, it
    resends the command, which is now processed cleanly, even with
    inaccurate end of frame detection. If the gap detection fails almost
    constantly, the master must repeat each request once after the timeout
    period, slowing the scan rate significantly, if gap detection on all
    slaves is bad.

    If the master performs multiple operations with the same slave before
    switching to the next slave, the extra timeout only occurs, when
    switching from X to Y.

    On a "4-wire RS-485" network, the slaves only hear master requests and
    there are pauses as long as the slave responses on the other pair (or
    master timeouts), so the gap detection is far less critical.

    For point to point connections, the gap detection can be even more
    inaccurate, since a slow end-of-frame detection only reduces the
    throughput gradually.

    If accurate timing is not available (or destroyed by inaccurate
    ethernet/serial converters), the slaves can always listen to all
    traffic on the 2-wire RS-485 bus and syntactically decode all frames
    (assuming the master does not use some vendor specific function codes,
    when accessing special slave Z).

    Since you can not tell from the start of the frame, if a frame is a
    request to slave X or a response from X and hence these require a
    different decoding, you would have to first try to decode as the
    shorter alternative and after CRC checks and other heuristic checks
    determine if this was indeed the case or use the longer format and
    read more and try to decode it that way.

    A third method is to perform the CRC check after each character is
    received and assume the end-of-frame was detected. However, this
    method gives surprisingly often premature end-of-frame detections.
    Thus, when you get a preliminary CRC match, you need to perform a
    heuristic analysis, if this really could be a valid message.

    The last two methods may have problems when adding (or powering up) a
    slave in the middle of a transfer, since it may take a while, before
    the slave understands about frames and the first time the powered up
    slave is addressed, ther could be a timeout, which would force

    The syntax checker method suffers from unknown vendor specific
    function codes. The cumulative CRC method also suffer from these, as
    the heuristic checks can not be performed when a preliminary CRC match
    is detected.
  9. JosephKK

    JosephKK Guest

    Hmmm. I might have use for an I/O expander IF it is cheaper than
    another uC. Not sure which protocol i would use, i am looking at
    millisecond or less coordination.
  10. JosephKK

    JosephKK Guest

    Kind of highlights the fact that the original PC used an 8048 or
    similar to talk to the keyboard. As did a lot of the (desktop /
    workstation / test controllers) computers of the era. The reason is
    the same.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day