If the TX output of one device is holding it's output for 16 cycles and the= RX of the other device is sampling that for 16 cycles, haven't the clock d= omains effectively been decoupled for the purposes of metastability for the= 14 cycles between the possible iffy cycles? i.e. the input to the RX for 1= 4 cycles might as well be tied hi or lo since nothing else is happening fro= m the TX device. On 2011-07-02, at 11:50 PM, Sean Breheny wrote: > Sorry, I disagree. The problem I am talking about could cause an > internal condition within the UART logic which could never happen if > you assume the simple model that the input is always either true or > false (high or low). Without more details of how the UART is > implemented internally, it is not possible to know what effects this > might have. >=20 > Sean >=20 >=20 > On Sun, Jul 3, 2011 at 2:33 AM, Veronica Merryfield > wrote: >> Sean >>=20 >> Assuming that the data line is being held for a nominal 16 cycles, then = for at least 14 of those cycles, the data is stable at a FF on a clock edge= .. The only time that metastability might be an issue is at the first and la= st as the data changes. >>=20 >> Veronica >>=20 >> On 2011-07-02, at 10:19 PM, Sean Breheny wrote: >>=20 >>> Hi Veronica, >>>=20 >>> Yes, I understand how UARTs work. Just as all logic circuits, they >>> depend on internal consistency. If two signals within the UART are >>> both supposed to be at the same value as the sampled input, but they >>> instead differ because they come from two different logic gates which >>> were "asked" to interpret an invalid logic level and they did so >>> differently, then all bets are off. The 16x sampling is intended to >>> help reduce noise sensitivity - it has nothing to do with the problem >>> I am talking about. >>>=20 >>> Sean >>>=20 >>>=20 >>> On Sun, Jul 3, 2011 at 12:30 AM, Veronica Merryfield >>> wrote: >>>>=20 >>>> On 2011-07-02, at 8:57 PM, Sean Breheny wrote: >>>>=20 >>>>> Let's make things more concrete: let's say I have two PICs >>>>> communicating via their internal USARTs in asynchronous mode. >>>>=20 >>>> In which case it doesn't matter a jot if the clocks are the same or no= t. From a PIC data sheet on the UART... >>>>=20 >>>> "The data recovery block operates at 16 times the baud rate, whereas t= he main receive serial shifter operates at the baud rate. After sampling th= e UxRX pin for the Stop bit, the received data in UxRSR is transferred to t= he receive FIFO (if it is empty). >>>>=20 >>>> The data on the UxRX pin is sampled three times by a majority detect c= ircuit to determine if a high or a low level is present at the UxRX pin." >>>>=20 >>>> Two things to note - >>>> 1. the sampling of the data pin is at 16x the baud rate. This is commo= n practise for most UARTs and variants. >>>> 2. the UART logic is looking for a level not an edge. >>>>=20 >>>> However, there are other reasons why a common clock might not be a goo= d idea but it can work out. >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> http://www.piclist.com PIC/SX FAQ & list archive >>>> View/change your membership options at >>>> http://mailman.mit.edu/mailman/listinfo/piclist >>>>=20 >>> -- >>> http://www.piclist.com PIC/SX FAQ & list archive >>> View/change your membership options at >>> http://mailman.mit.edu/mailman/listinfo/piclist >>=20 >>=20 >> -- >> http://www.piclist.com PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >>=20 >=20 > --=20 > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .