Yep. Actually, a good UART, not a cheap or universal one, would be able to resync with a "too early" first stop-bit as it would be edge triggered. It would also detect the timing error. Kyrre ----- Original Message ----- From: "Bob Axtell" To: Sent: Monday, June 28, 2004 12:11 AM Subject: Re: [PIC:] 16F88 RS232 bootloader. > You can overcome SOME timing errors by simply adding a short wait > between each character, in both directions. Usually, just setting the PC > to N/8/2 (2 stop bits) handles it from that end. On the PIC end, just a > simple wait of 2-stop bit length will do. > > It makes the process slower, but allows the UARTS to resynch. > > --Bob > > Kyrre Aalerud wrote: > > > The transmission medium in our case is a serial datastream. There is no > > clock in the data, or on seperate channel. It is usually asynchronous. > > Asynchronous communication is actually most prone to error on the MSB if one > > transmits data in the usual LSB to MSB fashion. > > > > The timing error for one bit is accumulated to the last bit. If we use a > > centered-sample we might get an error if the bit-error is more than 50% > > divided by number of bits pr word transmitted at a time. Shorter words mean > > more overhead but also more resynchronization between sender and receiver. > > With the accuracy of the oscillators and the ability to either use baudrate > > generators or bit-banging to within less than 4% pr bit, the errors in the > > transmission would come from other sources. > > > > Anyway, MSB is most "fragile" so it is important to use a checksum that can > > protect this bit. > > > > (16F88 has a typical accuracy of +/- 1% but a worst case +/- 2%. As long as > > one uses a bitrate with less than 2% error one should actually be quite > > safe. That is, assuming a centered sample on the receiving end.) > > > > > > Kyrre > > > > > > ----- Original Message ----- > > From: "William Chops Westfield" > > To: > > Sent: Sunday, June 27, 2004 11:44 PM > > Subject: Re: [PIC:] 16F88 RS232 bootloader. > > > > > > > >>On Jun 27, 2004, at 9:01 AM, Byron A Jeff wrote: > >> > >> > >>> However after some emperical testing it's clear that the error rate > >>>is in fact the same. There's no difference in the robustness of > >>>addition vs. xor when the checksum size is the same and the sample > >>>size is large. > >>> > >> > >>Certain types of checksums are worse at detecting certain types of > >>errors that others. An ADD is better than an XOR if a particular bit > >>happens to be prone to errors, for instance. Two errors on the same > >>bit with an xor cancel each other out, not not necessarilly so for ADD. > >>(although the high bit is more sensitive for add, which is why things > >>like the IP checksum use end-around carry.) CRCs that are very good at > >>detecting 'all single bit errors and 99.9% of double bit errors' might > >>really suck if the comm link normally drops or trashes 8 or more bits > >>at a time. It's all pretty much "black magic" to me, expect for the > >>fact that it means that you need to pay attention if you're going to > >>deviate much from standard practices... > >> > >>BillW > >> > >>-- > >>http://www.piclist.com hint: The PICList is archived three different > >>ways. See http://www.piclist.com/#archives for details. > >> > > > > > > -- > > http://www.piclist.com hint: The PICList is archived three different > > ways. See http://www.piclist.com/#archives for details. > > > > > > > -- > > Replier: Most attachments rejected > -------------- > Bob Axtell > PIC Hardware & Firmware Dev > http://beam.to/baxtell > 1-520-219-2363 > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.