Well, I think they don't wait until end of stopbit as that's not defined, but that's only a detail (or maybe I just misunderstood the "2/4/6/stop" - I would write "0/2/4/6").

Anyway, you are right, this will reduce the impact of error coming from granularity of measurement (jb+jnb -> 4 instruction cycles) to 1/8 (and depending on particular implementation maybe less thanks to rounding) and also the error from assymetry of 1's and 0's.

On the other hand, this is not an absolutely perfect solution in its own, either. It requires that the "U" character will arrive AFTER the wait for startbit started. If the autobauding starts in middle of a transmitted character, it might result in error, too.

A great example is the 'U' being transmitted continouosly with no space between bytes but with 2 stopbits... If the autobaud routine starts in the middle of transmitted byte, both the Philips and the Atmel algorithm will fail, but both from a different reason: the Atmel's will autobaud to a different speed due to one bit detected twice as long (this might be irrelevant at low speeds), the Philips' will detect the correct speed, but then will see a row of characters different from 'U' (with two 1s after each other), so it will never echo 'U' back...

It seems that the advice of autobauding at as low baudrate as possible corrects most of the problems that may occur. A great combination is to start the autobaud at a low baudrate, then send the reload value explicitly using the bootloader protocol and switch the PC's baudrate accordingly - if the bootloader protocol (and the PC program) support it - P89xxx's (and FM) do, (A)T89xxx's (and Flip) don't.

As for Dallas, there is no knowledge on the exact working of bootloader's autobaud (except what is written in the manual), as the bootloader is not located in user accessible space (nor accessible in other way). HOwever, the note stating that low baudrates are recommended make me believe that it suffers from problems not dissimilar to Philips' bootloader autobaud.

Jan Waclawek