Data Link Protocol Description by Daniel L. Henry Revision 1.1 October 9, 2011 Copyright 2000-2011 by Daniel L. Henry
Revision History Rev. Date Changed By Reason for Change 1.0 5/9/03 Dan L. Henry Made suitable for external use. 1.1 10/9/11 Dan L. Henry Update to ISO/IEC 13239:2002. i
Contents 1 INTRODUCTION... 1 1.1 PURPOSE... 1 1.2 SCOPE... 1 1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS... 1 1.3.1 Definitions... 1 1.3.2 Acronyms and Abbreviations... 1 1.4 REFERENCES... 2 1.5 DOCUMENT CONVENTIONS... 2 1.6 OVERVIEW... 2 2 HDLC FRAME STRUCTURE... 3 2.1 GENERAL FRAME FORMAT... 3 2.2 ELEMENTS OF THE FRAME... 3 2.2.1 Flag Sequence... 3 2.2.2 Address Field... 3 2.2.3 Control Field... 3 2.2.4 Information Field... 3 2.2.5 Frame Checking Sequencing (FCS) Field... 3 2.3 BCC FRAME FORMAT... 4 2.4 TRANSPARENCY... 4 2.5 INVALID FRAME... 4 3 PROTOCOL OPERATION... 4 3.1 GENERAL... 5 3.2 DESCRIPTION OF THE DATA LINK... 5 3.2.1 Configuration... 5 3.2.2 Physical Layer Transmission Facilities... 5 3.3 DESCRIPTION OF THE PROCEDURES... 5 3.3.1 General... 5 3.3.2 Balanced Connectionless Station Characteristics... 5 3.3.3 Detailed Definition of the Procedures... 5 4 C CODE EXAMPLES... 7 4.1 FCS CALCULATION... 7 4.2 BCC 15.1 FRAME TRANSMIT... 9 4.3 BCC 15.1 FRAME RECEIVE... 10 ii
1 Introduction The introduction of this Communication Protocol Description (CPD) provides an overview of the entire CPD. 1.1 Purpose Communication protocols are sets of rules that govern the interaction of concurrent processes in distributed systems. A protocol specification consists of five parts. To be complete, each specification should include: 1. The service(s) to be provided by the protocol 2. The assumptions about the environment in which the protocol is executed 3. The vocabulary of messages used to implement the protocol 4. The encoding (format) of each message in the vocabulary 5. The procedure rules guarding the consistency of message exchanges This CPD attempts to address all of these parts, describing the protocol without ambiguity. 1.2 Scope This CPD describes the High-level Data Link Control (HDLC) Balanced operation Connectionless mode Class (BCC) protocol. Communication protocol layers above and below the data link layer (e.g., the application or physical layers) are beyond the scope of this document. The intended audience of this CPD is Project Management and Engineering Staff who are responsible for reviewing the communications protocol design prior to implementation and who are responsible for product enhancement and software maintenance. 1.3 Definitions, Acronyms, and Abbreviations This section defines the terms used in this specification. Words in italics indicate terms that are defined elsewhere in the list of definitions. 1.3.1 Definitions Control escape (CE) The unique sequence of eight bits (01111101) employed to indicate the following octet has been modified according to the transparency algorithm for start/stop transmission environments. Flag sequence (FS) The unique sequence of eight bits (01111110) employed to delimit the opening and closing of a frame. Frame The unit of transmission at the data link layer. For HDLC it is the sequence of address, control, information, and FCS fields, bracketed by opening and closing flag sequences. Frame check sequence (FCS) The field immediately preceding the closing flag sequence of a frame, containing the bit sequence that provides for the detection of transmission errors by the receiver Octet ISO/IEC parlance for a sequence of eight bits (also known as a byte ) 1.3.2 Acronyms and Abbreviations BCC Balanced operation Connectionless mode Class (of HDLC) CPD Communication Protocol Description DLP Data Link Protocol FCS Frame Check Sequence HDLC High-level Data Link Control IEC International Electrotechnical Commission INFO INFOrmation field ISO International Organization for Standardization LSB Least Significant Bit MSB Most Significant Bit 1
1.4 References Information directly related to the subject of this CPD is found in the following document(s): 1. Information Technology Telecommunications and information exchange between systems High-level data link control (HDLC) procedures (ISO/IEC 13239:2002(E)). ISO/IEC, 2002-07-15 1.5 Document Conventions Hexadecimal values are identified (where not clear from context) by prefixing the value with 0x. Binary values are identified (where not clear from context) by prefixing the value with 0b. Several notational conventions are used in this document to visually differentiate text. Courier Italic Courier Program or algorithm text, input, output, file names, regular expressions, or other text where use of a mono-spaced font enhances readability Formal parameters to be replaced by user-specified names or values Any CPD that uses the phrase to be determined (TBD) is not a complete CPD. The TBD is, however, a necessity when a CPD is being developed. TBDs are indicated in the document using italics in the form [TBD: ]. The TBD should be accompanied by: a) A description of the conditions causing the TBD (for example, why an answer is not known) so that the situation can be resolved b) A description of what must be done to eliminate the TBD, who is responsible for its elimination, and by when it must be eliminated 1.6 Overview This CPD describes HDLC BCC (balanced operation connectionless-mode class) and its optional function 15.1 (start/stop (asynchronous) transmission with basic transparency). BCC does not provide mechanisms for link initialization, flow control, error control (although it does provide error detection), or timeout recovery that are associated with some HDLC classes of procedures. BCC 15.1 is a point-to-point protocol and is virtually identical to PPP in HDLC-like Framing defined by Internet RFC 1662 (http://www.faqs.org/ftp/rfc/rfc1662.txt) using the minimal transparency implementation. That RFC only describes PPP s message framing component, not PPP in its entirety. The connectionless aspect of BCC in a pointto-point data link is somewhat analogous to UDP s (datagram) role on networks. UDP is described in Internet RFC 768 (http://www.faqs.org/ftp/rfc/rfc768.txt). HDLC and BCC are described in International Standard ISO/IEC 13239:2002. This CPD summarizes the relevant portions of the Standard, but not verbatim, since the Standard is copyrighted. Be aware that the Standard uses a bit numbering convention where bits are printed and numbered LSB-first, from 1 through 8, whereas this CPD uses the convention where bits are printed and numbered MSB-first, from 7 through 0. 2
2 HDLC Frame Structure In HDLC, all transmissions are in frames. The frame format structure does not include bits inserted for bitsynchronization (i.e., start or stop elements) or bytes inserted for transparency. 2.1 General Frame Format Each frame consists of the following fields (left to right transmission sequence, hexadecimal values): where.------+---------+---------+---------+---------+------. Flag Address Control Info. FCS Flag 7E 1 byte 1 byte n bytes 2 bytes 7E '------+---------+---------+---------+---------+------' Flag Address Control Info. FCS = flag sequence = data station address field = control field = information field = frame checking sequence field Frames containing only control sequences form a special case where there is no information field. The format for these frames is:.------+---------+---------+---------+------. Flag Address Control FCS Flag 7E 1 byte 1 byte 2 bytes 7E '------+---------+---------+---------+------' 2.2 Elements of the Frame 2.2.1 Flag Sequence All frames start and end with the flag sequence 0x7E (ASCII ~, tilde). All stations attached to the data link continuously hunt for this sequence. Thus, the flag is used for frame synchronization. A single flag may be used as both the closing flag for one frame and the opening flag for the next frame if the next frame immediately follows the previous frame without any idle line time (i.e., back-to-back). 2.2.2 Address Field The address field immediately follows the opening flag and identifies the station for which the command is intended. BCC specifies a point-to-point connection with the other station, so both stations use the all stations address 0xFF. 2.2.3 Control Field The control field indicates the type of commands or responses. BCC s command repertoire has only the Unnumbered Information (UI) command, thus the control byte always has the value 0x03. 2.2.4 Information Field Information may be any sequence of bytes (including none; i.e., null ). The information field contains the bytes used by the upper layer protocol. 2.2.5 Frame Checking Sequencing (FCS) Field The frame checking sequence is calculated for the entire length of the frame, excluding the opening flag, the FCS, or any bytes inserted for transparency. The length of the designated portion of the frame being protected by the FCS checking mechanism should not be greater than 2 15-1 bits (4095 bytes) in length. The 16-bit FCS shall be the ones complement of the sum (modulo 2) of a) the remainder of x k (x 15 + x 14 + x 13 + x 12 + x 11 + x 10 + x 9 + x 8 + x 7 + x 6 + x 5 + x 4 + x 3 + x 2 + x + 1) divided (modulo 2) by the generator polynomial x 16 + x 12 + x 5 + 1, where k is the number of bits being protected by the FCS and b) the remainder of the division (modulo 2) by the generator polynomial x 16 + x 12 + x 5 + 1 of the product of x 16 by the content of the k bits being protected. 3
As a typical implementation, at the transmitter, the initial content of the register of the device computing the remainder of the division is preset to all ones and is then modified by division by the generator polynomial (as described above) of the address, control and any remaining bits of the designated k bits being protected; the ones complement of the resulting remainder is transmitted as the 16-bit FCS. At the receiver, the initial content of the register of the device computing the remainder is preset to all ones. The final remainder after multiplication by x 16 and then division (modulo 2) by the generator polynomial x 16 + x 12 + x 5 + 1 of the serial incoming protected bits and the FCS will be 0b0001110100001111 (x 15 through x 0, respectively) in the absence of transmission errors. Several software FCS implementations are provided in section 4 of this CPD. 2.3 BCC Frame Format Sections 2.2.2 and 2.2.3 above define fixed values for a frame s address and control fields:.------+---------+---------+---------+---------+------. Flag Address Control Info. FCS Flag 7E FF 03 n bytes 2 bytes 7E '------+---------+---------+---------+---------+------' Thus, a frame with no information field has a fixed FCS:.------+---------+---------+---------+------. Flag Address Control FCS Flag 7E FF 03 1C C2 7E '------+---------+---------+---------+------' 2.4 Transparency BCC 15.1 uses start/stop (asynchronous) transmission and a control-octet (byte stuffing) transparency mechanism. The Control Escape byte is defined as 0x7D. Flag Sequence (0x7E) and Control Escape (0x7D) bytes must be escaped. After FCS computation, the transmitter examines the entire frame between the two Flag Sequences. Each Flag Sequence or Control Escape byte is replaced by a two-byte sequence consisting of the Control Escape byte followed by the original byte exclusive-or ed with 0x20. On reception, prior to FCS computation, each Control Escape byte is removed and the following byte is exclusiveor'ed with hexadecimal 0x20, unless it is the Flag Sequence (which aborts a frame). A few examples may make this clearer. Escaped data is transmitted on the link as follows: 0x7E, after incorporation into the FCS computation, is encoded and transmitted as 0x7D, 0x5E 0x7D, after incorporation into the FCS computation, is encoded and transmitted as 0x7D, 0x5D The opposite occurs when receiving: 0x7D, 0x5E is decoded into 0x7E, then 0x7E is incorporated into the FCS computation 0x7D, 0x5D is decoded into 0x7D, then 0x7D is incorporated into the FCS computation 2.5 Invalid Frame An invalid frame is defined as one that is not properly bounded by two flags, or one that is too short (i.e., shorter than four bytes between flags, excluding bytes inserted for transparency), or one in which byte framing is violated (i.e., a "0" bit occurs where a stop element is expected), or one that ends with a Control Escape closing Flag Sequence (i.e., 0x7D 0x7E). Invalid frames are ignored and are silently discarded without passing them to the upper layer protocol. 3 Protocol Operation The following subsections are adapted from ISO/IEC 13239:2002 section 6.14 Balanced connectionless operation (point-to-point). 4
3.1 General The following requirements apply to the procedure for balanced connectionless operation of asynchronous data transmission over point-to-point data links with two-way alternate or two-way simultaneous data transfer. The procedure uses the HDLC frame structure defined in section 2. It uses the basic command/response repertoire designated BCC (i.e., a single command, Unnumbered Information [UI], and no response). 3.2 Description of the Data Link 3.2.1 Configuration The balanced connectionless operation data link configuration consists of two peer stations interconnected by physical layer transmission facilities. 3.2.2 Physical Layer Transmission Facilities The physical layer transmission facilities may provide either half-duplex or duplex transmission over switched or non-switched data circuits. NOTE: In the case of a switched data circuit, the procedures described assume that the switched data circuit has been established. The physical layer must provide an indication of circuit availability before the data link layer initiates transmission. (In some systems providing two-way alternate data exchange on physical layer data circuits using half-duplex transmission, the indication of physical layer circuit availability is indicated by an idle data link channel state.) 3.3 Description of the Procedures 3.3.1 General Balanced connectionless control procedures operate on a data link where the data station at each end of the data link is a peer station. Each peer station is responsible for sending UI command frames and receiving UI command frames, but is not responsible for connection establishment/termination, flow control, acknowledgements, or error recovery. Each peer station checks incoming frames for correct frame check sequence and correct frame format. Incorrect frames are discarded without notification to the other peer station. 3.3.2 Balanced Connectionless Station Characteristics Each station is a peer station, able to both send and receive UI command frames without the need for a data link connection to be established. 3.3.3 Detailed Definition of the Procedures The procedures for a point-to-point data link using a permanently connected (dedicated) or an established switched connection are defined in 3.3.3.1 to 3.3.3.5. The protocol for establishing and disconnecting a switched data circuit is not within the scope of this CPD. 3.3.3.1 Setting Up and Disconnecting the Data Link [There are no data link set-up procedures or data link disconnect procedures in the balanced connectionless class of procedures.] 3.3.3.2 Exchange of Unnumbered Information (UI) Frames 3.3.3.2.1 Sending UI Frames The control field has a value of 0x03 for a UI frame. The maximum length of the information field in UI frames is a system-defined parameter. Whenever a peer station is ready to send a UI command frame, it sends it immediately since there is no flow control in connectionless class service. 3.3.3.2.2 Receiving UI Frames When a peer station correctly receives a UI command frame that it can accept, the information field contents are passed up to the upper layer protocol. If the peer station is unable to accept the correctly received UI command frame, it discards the information field contents. 3.3.3.2.3 Reception of Incorrect Frames 5
A peer station silently discards frames received with an incorrect FCS, or with incorrect format. 3.3.3.2.4 Balanced Connectionless Station Receiving Acknowledgements Peer stations do not operate with acknowledgements. 3.3.3.3 Time-out Considerations In order to detect a no-activity condition in two-way alternate configurations, each peer station implements a noactivity time-out function (or equivalent) - idle data link channel state detector. The expiry of this time-out function (or equivalent) is available for use to initiate transmission of UI command frames. The duration of this time-out function (or equivalent) is system-dependent. The duration of the time-out function (or equivalent) in the two peer stations must be unequal in two-way alternate operation in order to resolve contention situations. This time-out function (or equivalent) is started whenever the peer station observes a steady idle state condition. Upon receiving a UI command frame, the time-out function (or equivalent) is stopped. If the no-activity time-out function (or equivalent) runs out, a UI command frame may be transmitted. 3.3.3.4 Two-way Alternate Considerations In two-way alternate data link operation, transmission from a peer station is not allowed until either: a) detection of an idle data link channel state after receipt of a frame or a flag; or b) the end of an extended period of inactivity (idle data link channel state). NOTE: In the case of half-duplex data circuit facilities, appropriate accommodation must be made to control the direction of data transmission. The direction of transmission is controlled by the data link layer, and may be signaled by the physical layer. If no frames were transmitted from either peer station for quite some time and information becomes available for transmission, it is advisable that the peer station transmits at first a UI command frame with a zero length information field in order to avoid long timer recovery action, which would occur in the case of contention of UI frames with information. If a peer station has transmitted frames and no further frames are pending for transmission, it gives the right to transmit to the remote peer station. 3.3.3.5 Two-way Simultaneous Consideration Two-way simultaneous operation may be used independent of physical data circuit capability (i.e., half-duplex or duplex transmission). However, in the case of half-duplex data circuit facilities, appropriate accommodation must be made to control the direction of data transmission. The direction of transmission is controlled by the data link layer. 6
4 C Code Examples These examples are for illustrative purposes only. They have been verified to work, however. Practical implementations may partition data link and physical layer functions differently. For example, some DLP functionality and physical device interface might be together in an interrupt service routine. 4.1 FCS Calculation / FCS manifest constants #define FCS_INIT 0xFFFF / Initial FCS value #define FCS_GOOD 0xF0B8 / Good FCS remainder / FCS feedback table static const uint16_t feedback[256] = { 0x0000, 0x1189, 0x2312, 0x329B, 0x4624, 0x57AD, 0x6536, 0x74BF, 0x8C48, 0x9DC1, 0xAF5A, 0xBED3, 0xCA6C, 0xDBE5, 0xE97E, 0xF8F7, 0x1081, 0x0108, 0x3393, 0x221A, 0x56A5, 0x472C, 0x75B7, 0x643E, 0x9CC9, 0x8D40, 0xBFDB, 0xAE52, 0xDAED, 0xCB64, 0xF9FF, 0xE876, 0x2102, 0x308B, 0x0210, 0x1399, 0x6726, 0x76AF, 0x4434, 0x55BD, 0xAD4A, 0xBCC3, 0x8E58, 0x9FD1, 0xEB6E, 0xFAE7, 0xC87C, 0xD9F5, 0x3183, 0x200A, 0x1291, 0x0318, 0x77A7, 0x662E, 0x54B5, 0x453C, 0xBDCB, 0xAC42, 0x9ED9, 0x8F50, 0xFBEF, 0xEA66, 0xD8FD, 0xC974, 0x4204, 0x538D, 0x6116, 0x709F, 0x0420, 0x15A9, 0x2732, 0x36BB, 0xCE4C, 0xDFC5, 0xED5E, 0xFCD7, 0x8868, 0x99E1, 0xAB7A, 0xBAF3, 0x5285, 0x430C, 0x7197, 0x601E, 0x14A1, 0x0528, 0x37B3, 0x263A, 0xDECD, 0xCF44, 0xFDDF, 0xEC56, 0x98E9, 0x8960, 0xBBFB, 0xAA72, 0x6306, 0x728F, 0x4014, 0x519D, 0x2522, 0x34AB, 0x0630, 0x17B9, 0xEF4E, 0xFEC7, 0xCC5C, 0xDDD5, 0xA96A, 0xB8E3, 0x8A78, 0x9BF1, 0x7387, 0x620E, 0x5095, 0x411C, 0x35A3, 0x242A, 0x16B1, 0x0738, 0xFFCF, 0xEE46, 0xDCDD, 0xCD54, 0xB9EB, 0xA862, 0x9AF9, 0x8B70, 0x8408, 0x9581, 0xA71A, 0xB693, 0xC22C, 0xD3A5, 0xE13E, 0xF0B7, 0x0840, 0x19C9, 0x2B52, 0x3ADB, 0x4E64, 0x5FED, 0x6D76, 0x7CFF, 0x9489, 0x8500, 0xB79B, 0xA612, 0xD2AD, 0xC324, 0xF1BF, 0xE036, 0x18C1, 0x0948, 0x3BD3, 0x2A5A, 0x5EE5, 0x4F6C, 0x7DF7, 0x6C7E, 0xA50A, 0xB483, 0x8618, 0x9791, 0xE32E, 0xF2A7, 0xC03C, 0xD1B5, 0x2942, 0x38CB, 0x0A50, 0x1BD9, 0x6F66, 0x7EEF, 0x4C74, 0x5DFD, 0xB58B, 0xA402, 0x9699, 0x8710, 0xF3AF, 0xE226, 0xD0BD, 0xC134, 0x39C3, 0x284A, 0x1AD1, 0x0B58, 0x7FE7, 0x6E6E, 0x5CF5, 0x4D7C, 0xC60C, 0xD785, 0xE51E, 0xF497, 0x8028, 0x91A1, 0xA33A, 0xB2B3, 0x4A44, 0x5BCD, 0x6956, 0x78DF, 0x0C60, 0x1DE9, 0x2F72, 0x3EFB, 0xD68D, 0xC704, 0xF59F, 0xE416, 0x90A9, 0x8120, 0xB3BB, 0xA232, 0x5AC5, 0x4B4C, 0x79D7, 0x685E, 0x1CE1, 0x0D68, 0x3FF3, 0x2E7A, 0xE70E, 0xF687, 0xC41C, 0xD595, 0xA12A, 0xB0A3, 0x8238, 0x93B1, 0x6B46, 0x7ACF, 0x4854, 0x59DD, 0x2D62, 0x3CEB, 0x0E70, 0x1FF9, 0xF78F, 0xE606, 0xD49D, 0xC514, 0xB1AB, 0xA022, 0x92B9, 0x8330, 0x7BC7, 0x6A4E, 0x58D5, 0x495C, 0x3DE3, 0x2C6A, 0x1EF1, 0x0F78 ; / fcs_16 calculates a new FCS given an initial (or current) FCS and new data. uint16_t fcs_16(uint16_t fcs_init, const unsigned char p, int len) { uint16_t fcs = fcs_init; while (len--) { fcs = (fcs >> 8) ^ feedback[(fcs ^ p++) & 0xFF]; return fcs; / fcs_16_a variation of fcs_16 does not use a feedback table. uint16_t fcs_16_a(uint16_t fcs_init, const unsigned char p, int len) { uint16_t fcs = fcs_init; while (len--) { fcs ^= p++; 7
fcs = (fcs >> 8) (fcs << 8); fcs ^= (fcs & 0xFF00) << 4; fcs ^= fcs >> 12; fcs ^= (fcs & 0xFF00) >> 5; return fcs; / fcs_16_b variation of fcs_16_a is optimized for most 8-bitters. @note Reading from a union member other than the member last written to is a common idiom, but not sanctioned by the language standard. uint16_t fcs_16_b(uint16_t fcs_init, const unsigned char p, int len) { unsigned char fcs_tmp; union { uint16_t w; unsigned char b[2]; fcs; fcs.w = fcs_init; / Endian awareness is required for fcs.b[]'s subscripts. Adjust for your hardware. #define BIG_ENDIAN 1 / 1 = big-endian, 0 = little-endian #if BIG_ENDIAN #define MSB 0 #define LSB 1 #else #define MSB 1 #define LSB 0 #endif while (len--) { fcs.b[lsb] ^= p++; fcs_tmp = fcs.b[msb]; fcs.b[msb] = fcs.b[lsb]; fcs.b[lsb] = fcs_tmp; fcs.b[msb] ^= fcs.b[msb] << 4; fcs.b[lsb] ^= fcs.b[msb] >> 4; fcs_tmp = fcs.b[msb] ^ ((fcs.b[msb] >> 4) >> 1); fcs.b[lsb] ^= fcs.b[msb] << 3; fcs.b[msb] = fcs_tmp; return fcs.w; / Example of FCS usage void use_fcs(unsigned char p, int len) { uint16_t fcs; / Append to output stream. fcs = fcs_16(fcs_init, p, len); fcs ^= 0xFFFF; / Complement p[len + 0] = fcs & 0x00FF; / LSB first p[len + 1] = (fcs >> 8) & 0x00FF; / Check input stream. if (fcs_16(fcs_init, p, len + 2) == FCS_GOOD) { printf("good FCS!\n"); 8
4.2 BCC 15.1 Frame Transmit This example assumes that the FCS_ manifest constants and feedback[] from section 4.1 are in scope. #include <stddef.h> #include <stdint.h> / HDLC manifest constants #define FS 0x7E / HDLC flag sequence #define CE 0x7D / HDLC control-escape #define CE_XOR 0x20 / HDLC escape XOR value / phy_tx() is the physical layer device driver's transmit function to transmit the byte 'b'. extern void phy_tx(uint8_t b); static uint16_t tx_fcs; static void tx_byte(uint8_t b); // @brief Transmit a UI frame. @param info_p Start address of INFO bytes to transmit. @param n Number of INFO bytes to transmit. void dlp_tx(void info_p, size_t n) { uint16_t fcs; uint8_t p = info_p; tx_fcs = FCS_INIT; phy_tx(fs); / Flag sequence "raw" tx_byte(0xff); / "All stations" addr tx_byte(0x03); / UI command / Transmit INFO. while (n--) { tx_byte(p++); / Transmit FCS, then FS. Save FCS locally before invoking tx_byte(). fcs = ~tx_fcs; tx_byte(fcs & 0x00FF); tx_byte((fcs >> 8) & 0x00FF); phy_tx(fs); / Flag sequence "raw" / tx_byte() with control-octet transparency, updating tx_fcs. static void tx_byte(uint8_t b) { tx_fcs = (tx_fcs >> 8) ^ feedback[(tx_fcs ^ b) & 0xFF]; if ((b == CE) (b == FS)) { phy_tx(ce); b ^= CE_XOR; phy_tx(b); 9
4.3 BCC 15.1 Frame Receive This example assumes that FCS_ manifest constants and feedback[]from section 4.1 are in scope. #include <stddef.h> #include <stdint.h> #include <time.h> / HDLC manifest constants #define FS 0x7E / HDLC flag sequence #define CE 0x7D / HDLC control-escape #define CE_XOR 0x20 / HDLC escape XOR value / phy_rx() is the physical layer device driver's receive function returning the received byte, PHY_RX_FRAMING_ERR, or PHY_RX_NONE. PHY_RX_' values are negative or >UINT8_MAX, so are out of a uint8_t's range. extern int phy_rx(void); // @brief Receive a UI frame. @param[in,out] buf_pp On input, the address of a receive buffer large enough for INFO plus 4 bytes of DLP overhead (HDLC address, control, and FCS bytes). On output, the start address of the frame's INFO bytes. @param[in,out] n On input, the receive buffer's size. On output, the number of INFO bytes received. @param tov Receive timeout value. @return Zero if a UI frame was successfully received; otherwise, nonzero indicates a timeout. int dlp_rx(void buf_pp, size_t n, clock_t tov) { uint8_t p, buf_p = buf_pp; size_t n_rx; / Counts ADDRESS, CONTROL and INFO bytes bytes int err; / Error flag int ce; / CE received flag uint16_t fcs; int b; clock_t start_clk = clock(); #define INIT_RX_VARS() do { \ p = buf_p; \ n_rx = 0; \ err = 0; \ ce = 0; \ fcs = FCS_INIT; \ while (0) INIT_RX_VARS(); for (;;) { b = phy_rx(); if (b == PHY_RX_NONE) { / Check for timeout if ((clock() - start_clk) >= tov) { return -1; else if (b == PHY_RX_FRAMING_ERR) {/ Frame invalidated INIT_RX_VARS(); else if (b == FS) { if ((n_rx < 4) / Short frame? 10
(fcs!= FCS_GOOD) / FCS error? ce / Abort? err / Buffer overrun? (buf_p[0]!= 0xFF) / Address error? (buf_p[1]!= 0x03)) { / Command error? / INIT_RX_VARS(); else { / Good UI frame. Return INFO address and INFO length. buf_pp = buf_p + 2; / Byte following HDLC control byte n = n_rx - 4; / Minus address, control, and FCS return 0; / Indicate success else if (b == CE) { ce = 1; / XOR next byte else { b &= 0xFF; if (ce) { ce = 0; b ^= CE_XOR; / XOR to original value / If there's room in the buffer, store the byte and incorporate it into the FCS calculation; otherwise, flag a buffer overrun error. if (n_rx < n) { n_rx++; p++ = b; fcs = (fcs >> 8) ^ feedback[(fcs ^ b) & 0xFF]; else { err = 1; 11