UART Question

[BrianHG]

And the answer to the question, can you detect a start bit, is, you always can't if the data stream is continuous,

You are talking about a UART being wired into an existing ongoing non-stop stream.  Yes, such a hookup will potentially continuously mess up the receiver until there is a large enough break in the source data.

I would call this either a failure in wiring or someone designing a receiver to spoof in an existing transmission stream at any time as you attach a probe.  Under normal circumstances, this should not happen but it is not impossible.  You would need to make your own UART to be sure how you re-align to such a broken source stream.  Another issue here may be if you are designing a special UART for RF radio receivers.  In this care, you need to design your own RXD UART design at the logic level for best results, or if the baud rate is low enough, you can attempt this in MCU code.  But, the general UARTs aren't designed to deal with over air RF UART streams which contain random static noise and edge timing noise on a regular basis.

[Peabody]

And the answer to the question, can you detect a start bit, is, you always can't if the data stream is continuous, with no idle periods, with certain data. I'm too lazy to try to come up with an example with exact data pattern this could happen with, but I have seen it happen,

Well if you or anyone else can come up with an example, I would love to see it.  I've never seen a UART implementation that inserts idle periods deliberately.  The ones I've seen have buffered transmit so they can always do continuous transmission.  And the data stream content doesn't matter at all.

[westfw]

I've never seen a UART implementation that inserts idle periods deliberately.

I've done it, in a commercial product, in an attempt to get TX interrupts on a multiple-uart card to all happen at the same time and thus reduce context switching overhead.  (ie I inserted a short idle period in the uart driver; not the uart itself.)

I think it helped some; that sort of thing can be really hard to measure!

[Siwastaja]

And the answer to the question, can you detect a start bit, is, you always can't if the data stream is continuous,

You are talking about a UART being wired into an existing ongoing non-stop stream.  Yes, such a hookup will potentially continuously mess up the receiver until there is a large enough break in the source data.

Yes, exactly, you got it  . Such a hookup is the easiest way to demonstrate the problem, but even if you specify a certain power-up sequence, so that one supposedly does not wire "into an existing" stream, the problem goes nowhere, as any loss of synchronization for whatever reason (SI, EMI, bug, etc.) causes the problem again. So it's not a robust system.

Adding idle periods (I personally use something like 10 bit times long, or slightly more) to force resynchronization every now and then is an actual solution to the actual problem and will limit the duration of the failure. If the system has some kind of packetized nature, then the obvious synchronization point is between the packets.

The attitude of blaming others when you have designed a flaky system which fails until power-off from any single communication failure is a BS attitude. And to design your own UART? What now, design your own USB-UART adapters and sell them with your system, and forbid using other brands of adapters in the user manual? Sounds like a massive case of Not Invented Here, and why? Just because you don't need to admit not knowing about a thing . Maybe just adapt the idle period resyncs instead, like everybody else does, and don't reinvent the wheel.

There are two types of people: those who can admit they did not know something, and enjoy the feeling of learning a new thing, and improve as engineers. And then there are those who go in defensive mode because they fear admitting they did not know it shows a weakness. This becomes a problem when they go to such great technical lengths as redesigning standard parts just to avoid admitting the mistake. This also explains why some products have a weird legacy and are PITA to deal with because of strange, non-standard conventions and requirements. Weird power sequencing requirements for no apparent reason easily cost days of development time at customer, and extra components, too, so they are generally frowned upon, and as a designer I rather choose a component with no such extra pain.

[Siwastaja]

I've never seen a UART implementation that inserts idle periods deliberately.  The ones I've seen have buffered transmit so they can always do continuous transmission.  And the data stream content doesn't matter at all.

Did you consider this:
1) They insert idle periods "nondeliberately", as a side effect of their communication pattern. Because every packet is shorter than the available time to send it, as is almost always the case, no one needs to think about the whole idle thing at all.
2) They insert idle periods deliberately, but because you had never considered this to be a problem, you did never recognize these idle periods are deliberate?
3) You have not even realized there are idle periods, because they are so short? (E.g., 10 bit times is easily lost if you look at it on a scope screen, and if it only happens once a second or so.)

This is a classic fallacy: the fact you don't know about some phenomenon makes it look like it doesn't exist, so you also miss clues about others knowing about the existence of it, and dealing with it - especially when it's very easy to deal with, sometimes "deliberate" way not even generating a single line of code.

These idle periods are "naturally occurring" in 99% of use cases of UART. Truly continuous streams of data are rare, I have never seen such a thing in existing products. The one case where continuous stream failed was my own product under development - could not get it to sync with two different USB-UART adapters -, which is also why I learned to add those idle periods.

[westfw]

The choice of 1.5 stop bits causes a shift word to word when out of sync so there is a chance after 8 to 10 words (bytes, characters, whatever) the link may sync up

BTW, I had never noticed before that using 1.5 stop bits would probably aid in the re-synchronization of data streams - thanks for pointing that out!

[Siwastaja]

The choice of 1.5 stop bits causes a shift word to word when out of sync so there is a chance after 8 to 10 words (bytes, characters, whatever) the link may sync up

BTW, I had never noticed before that using 1.5 stop bits would probably aid in the re-synchronization of data streams - thanks for pointing that out!

I never considered that either and it was an interesting point. While theoretically true, I would not count on it, because 1.5 stop bit setting has seen little use during last 20 years or so. Unless you develop your own UART peripheral (+ adapters), of course .

Besides, I prefer solutions where something can be guaranteed, with easily calculated maximum time, instead of "this solution may increase chances of success".

[Peabody]

Well of course I haven't studied every UART implementation, but the datasheets and devices I've looked at didn't reveal the existance of any added delay beyond the stop bit itself.  I was responding to the claim that the contents of the data stream could cause loss of sync, and am still looking for an example of that.  In any case, I think the answer to the OP's original question is that if he taps into an ongoing data stream, or the line is noisy or dropping out, then indeed there's no way to guarantee a resync unless there is some idle time.  But otherwise I don't think there is a problem even if transmission is continuous for an extended period, regardless of the contents of the data stream.  Opinions appear to differ on that, which is fine.

[BrianHG]

And the answer to the question, can you detect a start bit, is, you always can't if the data stream is continuous,

You are talking about a UART being wired into an existing ongoing non-stop stream.  Yes, such a hookup will potentially continuously mess up the receiver until there is a large enough break in the source data.

Yes, exactly, you got it  . Such a hookup is the easiest way to demonstrate the problem, but even if you specify a certain power-up sequence, so that one supposedly does not wire "into an existing" stream, the problem goes nowhere, as any loss of synchronization for whatever reason (SI, EMI, bug, etc.) causes the problem again. So it's not a robust system.

Always choose a baud rate slightly higher than you require.  All it takes is a blank time of a single character to re-synchronize.

You should preferably use a packet system with some king of checksum and re-transmit if necessary, but this isn't always required.

Many times I used a dummy 3.5x-4x my required data rate and just triple transmit everything capturing the best 2 out of 3, or at least 2 out of 3 for the packet headers plus data 1 time.