On Wed, Jun 10, 2009 at 23:20, Warren Turkalwt@penguintechs.org wrote:
Technically speaking, the ACK/NAK ASCII codes don't need to be used, but I think that it would be much more approachable for folks implementing the protocol if the traditional ASCII codes were used.
Ok, i'll change those then - not a big issue for me.
Also, if you are using the NAK+ACK for synchronizing, it might be good to do more than one round, like NAK+ACK+NAK+ACK+NAK+ACK. I just pulled this suggestion out of the air, so maybe rs232 geeks can speak up as to whether it makes sense or not.
It might be worth it doing one additional SYNCNOP cycle with a condition that the NAK must be the first byte received (after giving the command) to make sure of the synchronization, but i wont do more than that because this synchronization function is pretty slow already (and kinda udelay-dependent).
It also might make sense to have the NOP for synchronization use some combination of 1's and 0's so that an improper speed configuration on the computer side would be less likely to cause problems. Again, rs232 geeks can tell us of if that suggestion makes sense.
I think that this is not necessary (see next "chapter"), altough i might change the protocol to have command 0x10 as SYNCNOP (returning NAK+ACK) and 0x00 as just NOP - returning ACK, this might improve the robustness of the protocol.
If the receiver samples 0x00 too slowly, it will get a byte with some bits set (in the on-the-line last bits). If the receiver samples 0x00 too fast, it will get 0x00, but also a stop bit error (framing error. stop bit = 0) and should be able to filter it out.
I'll modify all the code and specification and send a new patch (maybe today (this mail is sent 13:20)).