Here are my thoughts.
[*]CRC semantics, header included, separate, or header not checked, pre escaping, post escaping, 8 bits/16 (I vote 8)
8-bit vote for me. If comms is unreliable, it will probably be obvious, and therefore 8-bit is good enough.
My gut feeling is that CRC should be pre-escaping, and the header not checked. i.e. CRC the payload only. If the header is corrupt, it's most likely going to mess the whole frame up anyway.
[*]Flow control - hardware, software, ignoring incoming requests when busy - requirements for each etc.
Hardware, hardware hardware, unless there is a very compelling reason not to.
[*]Payload type bit flag for protocol/firmware use (eliminate the 20 limit at the expense of a header bit)
Good idea. I like this.
[*]Stretchy ints, yes or no, if yes, how, if no, how big for numbers.
Part 1, Yes (where already specified). Part 2, sometimes - eg, where Integers have no known future boundary. No point in specifying a stretchy integer for engine temperature for example, if it's going to melt before the temperature value saturates 1 byte of data! If the unthinkable happened, and new engines run at over 255 degrees, then we will just have to issue a new command payload type, with a revised format. (temperature will probably be a floating number anyway, so bad example, but you get the idea)
[*]Appendix A payload format details correct/incorrect etc.
Looks ok. I wonder if we should specify an end of String character. Byte Zero maybe? Otherwise, how do you send multiple variably sized strings in the same payload.
[*]Include extensive "basic" vars in part 1 spec for compatibility with simple devices that can't cope with flash protocols
?? (would require detailed thinking...)
Yeah, maybe. Perhaps instead of the STX byte 0xaa, you start with another byte, which proceeds with a text based interface. Do we need to worry about this now? Seems like work we dont need right now. Leave it for version 2?
[*]Acknowledgment form. I say empty = positive, full = stretchy int with error code of some sort. Thoughts?
Not sure really. It has a lot to do with how much processing capacity is available in the ECU, and the way the firmware is written.
[*]I've added quite a few things including :
[snip]
Good work!