Re: Suggestions for custom application-layer protocol?

From: Paul Keinanen (keinanen_at_sci.fi)
Date: 05/29/05

  • Next message: Grant Edwards: "Re: Suggestions for custom application-layer protocol?" 
    Date: Sun, 29 May 2005 20:14:19 +0300

    On Sun, 29 May 2005 15:11:42 -0000, Grant Edwards <grante@visi.com>
    wrote:

    >>>I once talked to somebody who used an interesting scheme to
    >>>detect Modbus RTU messages. He ignored timing completely (so
    >>>he could use HW FIFOs), and decided that he would just monitor
    >>>the receive bytestream for any block of data that started with
    >>>his address and had the correct CRC at the location indicated
    >>>by the bytecount. It meant that he had to have a receive
    >>>buffer twice as long as the max message and keep multiple
    >>>partial CRCs running, but I guess it worked.

    <some reordering>

    >> This calculation should be done on all frames, not just those
    >> addressed to you.
    >
    >The problem is that you don't kow where the frames start so the
    >phrase "on all frames" isn't useful.

    If the master starts after all slaves are ready waiting for the first
    message, they all know were the first message starts. When the correct
    CRC is detected, the end of the first frame is known and it can now be
    assumed that the next byte received will start the next frame :-).
    This continues from frame to frame.

    Everything works well as long as there are no transfer errors on the
    bus or any premature "CRC matches" within the data part of a message.
    If the sync is lost, unless broadcasting is used, is there any need to
    regain sync until the master addresses your slave ? The master will
    not get an answer to the first request, but it will resend the request
    after the resend timeout period. The slave only needs to be able to
    detect this timeout period, which would usually be a few hundred byte
    transfer times.

    If the slave pops up into an active bus, it will regain
    synchronisation, when the master will address it first time and it
    will resend the command after a timeout period, since it did not get a
    reply. The slave just needs to detect the long resend timeout.

    >> As long as you are not using broadcast messages, it should be
    >> sufficient for a multidrop slave to have just one CRC running
    >> (and check it after each byte received).
    >
    >How so? If you don't know where the frame started because you
    >can't detect timing gaps, you have to have a seperate CRC
    >running for each possible frame starting point, where each
    >"starting point" is any byte matching your address (or the
    >broadcast address).

    A shift, bit test and xor operation is needed for each data bit
    received to calculate the CRC into the CRC "accumulator". This
    calculation can be done for all received bytes when the end of frame
    gap is detected or eight bits can be calculated each time a new byte
    is received (actually calculate with the byte received two bytes since
    the current byte).

    >From a computational point of view, both methods are nearly equal. The
    only difference is that in the first case, the CRC accumulator is
    compared with the last two bytes in the frame (in correct byte order)
    only after the gap was detected, however in the latter case, the
    updated CRC accumulator must be compared with the two most recently
    received bytes each time a byte is received. Thus, the computational
    difference is only two byte compares for each received byte.

    Thus a single CRC accumulator is sufficient, if no broadcasts are
    expected.

    However, if it is required to receive broadcasts, then it might be
    justified to use about 260 parallel CRC accumulators (if the maximum
    size frames are expected). Each accumulator starts calculating from a
    different byte in the buffer. Each time a new character is received,
    the last two bytes (the CRC candidates) are compared with all 260 CRC
    accumulators and once a match is found, the start of that frame is
    also known and synchronisation is regained. After synchronisation is
    regained, one CRC accumulator is sufficient for keeping track of the
    frame gaps.

    Since the Modbus CRC is only 16 bits long, relying on solely the CRC
    calculations can cause premature CRC detections with the likelihood of
    1/65536 or about 16 ppm, so additional message header checks should be
    employed to detect these, before declaring a true CRC end of frame.

    Paul

  • Next message: Grant Edwards: "Re: Suggestions for custom application-layer protocol?"

    Relevant Pages

    • Re: Suggestions for custom application-layer protocol?
      ... If the slave doesn't see the other slaves ... >>his address and had the correct CRC at the location indicated ... > sufficient for a multidrop slave to have just one CRC running ... If you don't know where the frame started because you ...
      (comp.os.linux.embedded)
    • Re: Suggestions for custom application-layer protocol?
      ... If the slave doesn't see the other slaves ... >>his address and had the correct CRC at the location indicated ... > sufficient for a multidrop slave to have just one CRC running ... If you don't know where the frame started because you ...
      (comp.unix.programmer)
    • Re: crc on only data or including the address
      ... >For that i am implementing ethernet packet generator in the fpga. ... >am sending 64 bytes of frame from the fpga with the most significand ... Actually, what is sent is the FCS, which is bit reversed ... >2) Is CRC implemented on only data or on whole frame? ...
      (comp.arch.fpga)
    • Re: Suggestions for custom application-layer protocol?
      ... CRC is detected, the end of the first frame is known and it can now be ... The slave only needs to be able to ... updated CRC accumulator must be compared with the two most recently ...
      (comp.unix.programmer)
    • Re: Crc16 on power failure
      ... after the machine is restarted (power on in this case). ... XOR the CRC with the XOR of that word ... Compute the FCS of a frame, and add it at the end of the frame. ...
      (comp.arch.embedded)
    Loading