On Wed, Jun 10, 2009 at 23:20, Warren Turkal<w...@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)). -- urjaman -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot