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.
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 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.
Thanks, wt
On Wed, Jun 10, 2009 at 11:00 AM, Urja Rannikkourjaman@gmail.com wrote:
On Wed, Jun 10, 2009 at 13:34, Frieder Ferlemannfrieder.ferlemann@web.de wrote:
Hi,
from serial-flash-protocol.txt
#define S_ACK 0x10 #define S_NAK 0xBA
Could these be 0x06 and 0x15 respectively so it's more inline with http://en.wikipedia.org/wiki/C0_and_C1_control_codes ?
Why not but why to change. Is there some technical reason to follow the ASCII control codes in this binary protocol?
Maybe i should have called them S_OK and S_BAD, or S_YES and S_NO, or S_SMILE and S_FROWN :P
They are just two values used to represent success/failure in command execution - i dont really care much of their numerical values.
-- urjaman
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot