-
When receiverControl.wasEscape == 1, then the code accepts both HDLC_FRM_FLAG_SEQUENCE and HDLC_FRM_CONTROL_ESCAPE characters, although this should not happen. There is a high probability (99.6%) that such a situation will be detected later by invalid CRC, but it is not 100% sure.
-
The function waits at the beginning for the starting HDLC_FRM_FLAG_SEQUENCE character (so it is not expected it is the 1st character received). That implies that the reception of the HDLC packet might start in the middle of another one. Then if the algorithm reads ending HDLC_FRM_FLAG_SEQUENCE of such a packet it understands it as a starting HDLC_FRM_FLAG_SEQUENCE of the new packet, which is wrong as it will get out of sync. I think the function should always try to receive the correct HDLC packet within the specified timeout interval to get in-sync with HDLC protocol.
-
Also the magic literal constants used in the code would deserve at least some comment to explain them.
SLEEP(5);
...
timeout += 500;
When
receiverControl.wasEscape == 1, then the code accepts bothHDLC_FRM_FLAG_SEQUENCEandHDLC_FRM_CONTROL_ESCAPEcharacters, although this should not happen. There is a high probability (99.6%) that such a situation will be detected later by invalid CRC, but it is not 100% sure.The function waits at the beginning for the starting
HDLC_FRM_FLAG_SEQUENCEcharacter (so it is not expected it is the 1st character received). That implies that the reception of the HDLC packet might start in the middle of another one. Then if the algorithm reads endingHDLC_FRM_FLAG_SEQUENCEof such a packet it understands it as a startingHDLC_FRM_FLAG_SEQUENCEof the new packet, which is wrong as it will get out of sync. I think the function should always try to receive the correct HDLC packet within the specified timeout interval to get in-sync with HDLC protocol.Also the magic literal constants used in the code would deserve at least some comment to explain them.