EyezOn Forum

I'm still trying to understand the spec, but it seems like the checksum could theoretically have a CR/LF encoded in it since CR and LF are in the lower nibble of the ascii range.

This makes the protocol a little unpredictable, especially if the data lengths aren't fixed as well.

No?

(ok, the maybe data lengths can be predicted on tpi commands and only the application commands have variable lengths -- but what if the error is in the command code? Then my predicted data length is wrong and I'm back to not knowing if CR/LF is end-of-message, or data.)

I keep thinking/hoping -- "oh, the checksum is sent as a hex code encoded as ascii characters, guaranteed to be alphanumeric" ...but I don't think I'm right. Am I?

Rich

Ok.. Definitely time to go to bed. I think the hex code representing the checksum IS sent literally as ascii characters A-F0-9.

You are correct sir. All TPI comms are in human readable ASCII.

Thanks for confirming.

I had grabbed the python sample code and it had a big comment about possible CR/LF's in the checksum, and then I read the spec 5 times and kept coming to the same (incorrect) conclusion as the comment.