Well, imho, I don't think there is any difference in error-detecting
capability whether or not the escape chars are included in CRC...
but...
what if the 'calculated crc value' needs char-stuffing?
Should crc add escape char generated by itself?
Wouldn't it be cleaner if not?
Thanks
- jpaek
KURT PETERS wrote:
Thanks for all your help. Here's a semantics question. It seems that
CRC is "frame level" as you said, but when I look at the code for
serialP.nc, it looks like the CRC is only done on the packet level.
That is... the CRC is calculated, then the byte is sent to the "frame
layer" where an extra escape character (0x7d) can be placed into the
stream (see code snippet below).
SerialFrameComm.putData(txBuf[txIndex].buf) seems to call the
HdlcTranslateC.nc putData which adds the escaped sequence, when necessary.
If CRC is truly a frame CRC, the CRC calculation should include the
escape byte for escaped data, in my humble opinion.
case TXSTATE_INFO:
atomic {
txResult = call SerialFrameComm.putData(txBuf[txIndex].buf);
txCRC = crcByte(txCRC,txBuf[txIndex].buf);
++txByteCnt;
if (txIndex == TX_DATA_INDEX){
uint8_t nextByte;
nextByte = signal SendBytePacket.nextByte();
if (txBuf[txIndex].state == BUFFER_COMPLETE || txByteCnt >=
SERIAL_MTU){
txState = TXSTATE_FCS1;
}
else { /* never called on ack b/c ack is BUFFER_COMPLETE
initially */
txBuf[txIndex].buf = nextByte;
}
}
else { // TX_ACK_INDEX
txState = TXSTATE_FCS1;
}
}
break;
Your thoughts?
Regards,
Kurt
--
Jeongyeup Paek
Ph.D. student
Embedded Networks Laboratory
Department of Computer Science
University of Southern California
http://enl.usc.edu/~jpaek
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
