Any of you folks who have tried to communicate with a calculator via TI's protocol probably know how annoying it is to deal with. Hence, the TI-SDIP (Simple Data Interchange Protocol), which I've designed to be (hopefully) easy to implement on both sides of a link.

Spec draft:
http://media.taricorp.net/uploads/pub/ti-sdip-draft.txt

I'm looking for feedback, particularly possible oversights in my design, things that need clarification, or just thoughts on the utility of the protocol.
Tari, that's an amazingly-complete spec and very impressive in terms of RFC formatting to boot. There was one bone that I was concerned about picking, and on examination it appears my bone is indeed there for me to pick. In your RFC, you specify that the checksum is an "[e]ight-bit modular checksum of the entire packet up to this point," and give the following code for calculating or verifying a checksum:


Code:
   00 | cksum_verify:
   01 |    ld a,(hl)               ;PRV, RES, PID
   02 |    inc hl
   03 |    add a,(hl)              ;PSIZE
   04 |    ld b,(hl)
   05 |    inc b                   ;PSIZE+1 iterations
   06 | cksum_verify_loop:
   07 |    inc hl
   08 |    add a,(hl)              ;DATA, CKSUM last iteration
   09 |    djnz packet_cksum_loop
   10 | cksum_verify_done:
However, that checksumming method and code would be ineffective at detecting multiple bit-flips as long as the 2s-complement sum of the errors equals zero. I feel this is a weakness in as noisy a channel as the TI's link cable, and that it might be worthwhile to consider a longer checksum, perhaps with some shifting within it or other irregularity, and perhaps a more frequent checksum than at worst case every 1024 bytes.
Oh right, that's one thing I forgot to fix, too. You may note that the packet length field is 10 bits, but I'm using B as a loop counter. Need to go back and update that to use a 16-bit counter.

As for your concern, I considered a more complex checksumming algorithm (some sort of CRC), but dismissed it as too complex for easy implementation. Given your thoughts, though, I'll have a look back and see if it would be possible to do an 8-bit CRC instead.
The Tari wrote:
Oh right, that's one thing I forgot to fix, too. You may note that the packet length field is 10 bits, but I'm using B as a loop counter. Need to go back and update that to use a 16-bit counter.
Ah, I missed that, but excellent point.

The Tari wrote:
As for your concern, I considered a more complex checksumming algorithm (some sort of CRC), but dismissed it as too complex for easy implementation. Given your thoughts, though, I'll have a look back and see if it would be possible to do an 8-bit CRC instead.
Good stuff, tell me what you find.
A little Wikipedia-ing reveals Fletcher's Checksum, which is somewhat lower overhead than a typical CRC (which requires a series of shift+mask operations on each byte) and can be used to generate an 8- or 16-bit checksum with 4- or 8-bit word sizes, respectively. Additional overhead per byte for Fletcher's Checksum will probably work out to one or two instructions, which I feel is plenty acceptable.

Modifying the spec for that will have to wait for tomorrow, but I'm keen to hear any other criticisms/comments people have.
I'm sure this is nothing, and maybe I misread the spec, but it sounded like an empty NAK packet causes a resend, while a NAK packet containing a string forbids the sender from resending? I'm a little uncomfortable about what feels like an indirect, non-explicit signal to or not to resend. Smile
You're correct there, in that a NAK with a payload implies retransmission should not be attempted, but the only result of ignoring that hint would be having further packets NAKed until the retransmit limit were reached. Conversely, not attempting retransmission just ends up throwing an error that the user gets to deal with, which, while perhaps inconvenient, is up to the implementer to consider.
The Tari wrote:
You're correct there, in that a NAK with a payload implies retransmission should not be attempted, but the only result of ignoring that hint would be having further packets NAKed until the retransmit limit were reached. Conversely, not attempting retransmission just ends up throwing an error that the user gets to deal with, which, while perhaps inconvenient, is up to the implementer to consider.
I guess that makes sense, I can live with that. Sounds good.
Draft document has now been updated to reflect new use of Fletcher-16 checksum and includes a paragraph noting the purely advisory function of NAK payloads.

Now, does anybody else care to provide opinions? (Kerm is great and all, but I'm sure somebody else has an opinion...)
The Tari wrote:
Draft document has now been updated to reflect new use of Fletcher-16 checksum and includes a paragraph noting the purely advisory function of NAK payloads.

Now, does anybody else care to provide opinions? (Kerm is great and all, but I'm sure somebody else has an opinion...)
Excellent Tari, many thanks. I hope some other people will indeed weigh in with their thoughts. Razz
Quote:
Every packet consists of a short header, payload of up to 255 bytes,
and checksum, as outlined in Figure 3, with the header containing
several subfields. Each field is detailed below.

PSIZE (PSH/PSL)
10-bit unsigned value giving the size of the packet's payload,
in bytes, in the range of 0 to 1023. PSH is the two high-order
bits of the value and PSL is the lower eight.


If the max payload size is 255 bytes, why is PSIZE 10 bits? Unnecessary complexity as far as I can tell.

NACKs should always have a payload with some reason set. You list several cases of why you would get a NACK without a payload - but the sender doesn't have a clue why they got NACKed. An enum of reasons would be good.
Kllrnohj wrote:
If the max payload size is 255 bytes, why is PSIZE 10 bits? Unnecessary complexity as far as I can tell.

Forgot to update that number after I changed PSIZE from 8 to 10 bits. Smile

Kllrnohj wrote:
NACKs should always have a payload with some reason set. You list several cases of why you would get a NACK without a payload - but the sender doesn't have a clue why they got NACKed. An enum of reasons would be good.

My intent is that a no-payload NAK implies there was probably some sort of link error, and anything else is a condition blocking reception- exactly what isn't terribly important, but the sender can report that error back to the user.

Thoughts? If that makes sense, I can just update it to note that, otherwise I'll look into enumerating some NAK messages.
The Tari wrote:
My intent is that a no-payload NAK implies there was probably some sort of link error, and anything else is a condition blocking reception- exactly what isn't terribly important, but the sender can report that error back to the user.

Thoughts? If that makes sense, I can just update it to note that, otherwise I'll look into enumerating some NAK messages.


Hence an enum of error codes, and some can be defined as retry-able.

The problem I see is that implementing it is going to suck. Sure, once you have it implemented and testing it is probably unnecessary, but if one side is doing the checksum wrong or something, you'll just get NACK'd with no clue why. Simply adding a single byte error code solves that, and I'm not seeing any reason to not have it.
Kllrnohj wrote:
The problem I see is that implementing it is going to suck. Sure, once you have it implemented and testing it is probably unnecessary, but if one side is doing the checksum wrong or something, you'll just get NACK'd with no clue why. Simply adding a single byte error code solves that, and I'm not seeing any reason to not have it.

And this is why I asked for feedback, as that hadn't occurred to me. Smile I'll work on it (although maybe not this weekend).
The Tari wrote:
Kllrnohj wrote:
The problem I see is that implementing it is going to suck. Sure, once you have it implemented and testing it is probably unnecessary, but if one side is doing the checksum wrong or something, you'll just get NACK'd with no clue why. Simply adding a single byte error code solves that, and I'm not seeing any reason to not have it.

And this is why I asked for feedback, as that hadn't occurred to me. Smile I'll work on it (although maybe not this weekend).
Yeah, I like that a lot better than a blind NACK, that's sorta what I was getting at. Maybe I'll even implement TI-SDIP over CALCnet if I get the link layer working. Smile
Draft has been updated once again, now including a mandatory payload for NAKs enumerating a reason for packet rejection, which greatly expanded section 3.2.2. Examples have also been updated to match the revised NAK format.
The Tari wrote:
Draft has been updated once again, now including a mandatory payload for NAKs enumerating a reason for packet rejection, which greatly expanded section 3.2.2. Examples have also been updated to match the revised NAK format.
Looks great, Tari, nice job on that. I meant to ask, do you have any plans to code up a prototype in the near future, or is that a far-future type of thing?
Yeah, a proper implementation is in my plans for.. sometime when I get around to further work on LIFOS. Which could very well be this week.
The Tari wrote:
Yeah, a proper implementation is in my plans for.. sometime when I get around to further work on LIFOS. Which could very well be this week.
That would be quite nice. If I ever get to CALCnet this fall, as I may have mentioned, I might try to implement this if you haven't already gotten to it. Smile
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement