UART Question - Page 1
Forum section: electronics / beginners

author: skysurf76
author_rank: Regular Contributor
timestamp: November 19, 2022, 07:19:38 pm
content: I've run into an interesting theoretical problem. Lets say we have two microcontrollers whose UARTs are connected together (rx-tx, tx-rx), and one is spitting out data at 115200 nonstop. 1 start bit, 1 stop bit, no parity, 8 data bits.We power up the second microcontroller and all it does is listen. We know that a stop bit is low, and a start bit is a transition from high to low. So at the end of every bit we have a low high low pattern.The question is what if we intentionally put that low high low pattern into the data that MCU1 is sending. How can MCU2 ever determine the boundaries of the data (where the byte begins and ends)?

author: AndyC_772
author_rank: Super Contributor
timestamp: November 19, 2022, 07:32:24 pm
content: It can't. Synchronisation requires a break character, which is effectively the line being high for more than a complete character's worth of time. This can be detected unambiguously, and from that point onwards, the first low bit is known to be a start bit.Note also that if you transmit continuously on a UART interface, then eventually you'll lose characters because of the slight difference in baud rate between the two ends. There must always be occasional breaks to ensure that the long-term average data rate from the transmitter doesn't exceed the Rx rate at the receiver.

author: skysurf76
author_rank: Regular Contributor
timestamp: November 19, 2022, 07:36:27 pm
content: Thats what I figured intuitively, but I couldn't find anything about it when searching for it. Thank you for the clarification!

author: wasedadoc
author_rank: Super Contributor
timestamp: November 19, 2022, 07:37:05 pm
content: Quote from: skysurf76 on November 19, 2022, 07:19:38 pmNot so. If adjacent bits are the same logical level there is no change of the UART's output voltage between them.

author: CaptDon
author_rank: Super Contributor
timestamp: November 19, 2022, 08:09:13 pm
content: This is why often you will see 1.5 or 2 stop bits selected. 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. Also, with UART's using a 16X or 64X clock, once sync'd they tend to stay sync'd even with slightly different clock speeds at each end. System throughput overruns are a major concern and is the reason for the handshaking signals. To prevent missing characters which is very important when the data is encrypted.

author: langwadt
author_rank: Super Contributor
timestamp: November 19, 2022, 08:28:07 pm
content: Quote from: AndyC_772 on November 19, 2022, 07:32:24 pmdepends on the UART, I quite sure some UARTs with start looking for a startbit as soon as they have seen the ~middle of the stop bit

author: Siwastaja
author_rank: Super Contributor
timestamp: November 20, 2022, 07:02:31 pm
content: It really can't. This is an inherent design flaw in UART, and it actually sometimes causes real problems. The solution is long enough idle time. The TX side must insert these idle slots, and RX side should not start to output anything before it detects at least one idle condition.But actual system designers often forget about this requirement, as it "usually" works out without any consideration, because many "typical" communication patterns have those idle periods anyway.EDIT: wrote break, meant idle.

author: David Hess
author_rank: Super Contributor
timestamp: November 20, 2022, 11:04:26 pm
content: Quote from: AndyC_772 on November 19, 2022, 07:32:24 pmThe receiving UART should be synchronizing on every start bit so baud rate drift is removed. I have never seen a UART lose synchronization because of continuous reception except when the signal was corrupted.Typically the input is sampled at 8 or 16 times the baud rate so the middle of the start bit is used for synchronization, and then each bit is sampled multiple times and majority logic used to determine the value.

author: langwadt
author_rank: Super Contributor
timestamp: November 21, 2022, 12:47:05 am
content: Quote from: David Hess on November 20, 2022, 11:04:26 pmthere is no transition in the middle of the start bit, the falling edge at the beginning of the startbit is what is used to find the middle of the bitsif the transmitter is slightly faster than the receiver that edge will happen before the end of the stop bit

author: westfw
author_rank: Super Contributor
timestamp: November 22, 2022, 12:58:23 am
content: QuoteA "break" character is the line being LOW for more than a complete character time. What you want for re-synchronization (and what you describe) is "line idle state." (line HIGH for a while.)Also, it doesn't actually have to last for more than a complete character time; it just has to continue till the idle state overlaps where there should be a stop bit. (a full byte+ time guarantees this.)QuoteIn theory, that's the "STOP bit" that is already present between characters. AFAIK, most UARTs wil report a "new" byte received as soon as they detect a STOP bit, which could be any HIGH state following the last data bit, or could be after whatever algorithm the UART uses to detect a "bit" (probably sampling about half way through the bit.) After "detecting" the stop bit, the UART will thenasynchronouslywait for the next START bit.This is why UARTs sample at (typically) 1/16 the baud rate, and what the "asynchronous" part in the name means; they do NOT require that the bits show up on bit-time clock edges.Also in theory, if the UART detects a "framing error", it will reset the logic and start looking for a start bit (LOW state) again.That means that with "random" continuous data will probably re-synchronize all by itself, after a while. A data pattern thatalwaysputs a HIGH state on the line when the UART expects a stop bit (and therefore does not cause a framing error) is pretty uncommon. Many "simple" UART drivers don't bother to do anything special WRT framing errors, but the UART hardware still does ... something.I've seen this happen in real life, with data sources like newswires connected to "Terminal Servers." Reboot the terminal server, and the data coming out the other end is wrong for some time, but ... not that long.UART receivers implemented in software (bit-banged) don't usually over-sample their bit detection, but may tie their start-bit detection to a much faster clock (ie some implementations use a pin-change interrupt to detect the start bit, so they're pretty much sampling the data at something near the CPU clock rate.)It would be an interesting experiment to see how short the stop bit can be before a UART doesn't like it...Different UART implementations may behave slightly differently. But not very much. This is really old technology at this point, such that anything that behaves significantly differently would be labeled "buggy."

author: CaptDon
author_rank: Super Contributor
timestamp: November 22, 2022, 01:57:07 am
content: David Hess and West, you guys are correct. There 'may' have been problems when UART's were clocked at 1X Baud Rate but when using 16X or 64X today's UART's do all the dirty work to stay in sync!!! We routinely transmit megabyte streams of data at 115K using the RS-232 signalling levels and I don't fear data loss. We routinely test with 'communication test fixtures' that let us intentionally mess with the baud rate raising or lowering it until errors are produced. You can really do some bad things until errors finally begin to show up!! One of the design goals of a good UART with oversampling clock is to intentionally re-sync at the beginning of every word thereby 'recentering' itself to anticipate the next start bit.

author: redkitedesign
author_rank: Regular Contributor
timestamp: November 22, 2022, 06:14:47 am
content: Quote from: skysurf76 on November 19, 2022, 07:19:38 pmit can't, and it doesn't matter. Since you need to continue inserting the fake stop and start bits in the dataword for MCU2 to continue considering the real start and stop bits as data bits, you are rather limited in the data you can actually transmit.One you start sending real data, the receiving MCU will find that any synchronization on databits fails, and will (depending on the quality of the MCU UART implementation) resync on another start bit. In the end, especially if there are breaks in the transmission (which can only end with a start bit) the receiving controller will resynchronize.Timing differences shouldn't be an issue: even if the RX is not byte-synced, there are enough edges in the signal (at least 2 per word) to keep a bit-clock synchronized.In theory, you could insert a stop and start bit in the middle of the data word, and then the two other halves (before and after the fake) could get swapped on reception.If that is a serious risk in your application, just put an extra 0-byte in your datagram.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 22, 2022, 04:22:34 pm
content: Quote from: CaptDon on November 22, 2022, 01:57:07 amDo you realize this had absolutelynothingto do with what was discussed on this thread? Did you accidentally post to a wrong thread?

author: voltsandjolts
author_rank: Unknown
timestamp: November 22, 2022, 04:41:21 pm
content: Quote from: skysurf76 on November 19, 2022, 07:19:38 pmIf you find yourself stuck in this situation (i.e. transmission is continuous) and you have to make it work, the only way I can see is by MCU2 firmware searching for a known unique character sequence. Switch the uart reception off and on (dead time of one bit time), search for that sequence, repeat until found. Yuk.Maybe if the transmission contains a very limited character set you could do something smarter?Maybe use a software "uart receiver" (just bit pattern detection really) initially to sync up, then switch to hardware uart at the correct time?

author: CaptDon
author_rank: Super Contributor
timestamp: November 22, 2022, 07:49:20 pm
content: Thanks for the smart-ass comeback Swi, So just put a 1.5 stop bit time in there. Every word that is incorrectly accepted do to incorrect start timing will shift by 1/2 bit time until the damn thing does finally gain syncronization!!! and 16X or 64X oversampling helps in this situation because NO F--king bit pattern will match the extra half-bit stop timing. Wasn't 1.5 stop bits common for RTTY on the old mechanical machines to help maintain the probability of regaining sync when it was lost due to fading or interference? That is how you fix a problem. As for the original question, if the bit pattern is 1010101010101010101 for ever maybe it won't sync but depending on the number of characters in a word which could be 5,6,7, or 8 you can't in some cases create the 10101010 or 01010101010 repeating pattern and for a robust link you would incorporate this to your advantage. This can be done by having the parity bit always hi or always low to create an extra long stop bit break. This also has nothing to do with the original post or the price of beans in China. Just wanted to bring that to your attention for your next snarky ass reply.

author: CaptDon
author_rank: Super Contributor
timestamp: November 23, 2022, 04:16:53 pm
content: The answer to the O.P.'s question, If you could create a perfect repeating bit pattern of 10101010101...... Then yes, there would be no way to identify a true start bit and a true stop bit without some sort of idle period to establish sync. An engineer tasked with creating a robust link would insure by way of 1.5 or 2 bit stop periods and also in some cases setting the parity bit to be the same as a stop bit and using 2 stop bits in addition. This would create an unusually long stop period that may help establish sync. Also with the choice of how many bits you will include (most UART's can be set to 5,6,7, oryou can create a situation where the repeating bit pattern is impossible and the link will re-sync by itself at some point. Yes, in a poorly implemented link it may be impossible to find syncronization but that possibility is designed out by good engineering practices.Sorry for my snarky comebacks.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 23, 2022, 04:21:29 pm
content: 1.5 stop bits works in theory but I wouldn't count on it because UARTs are notorious for having implementations which lack features or are outright buggy. 1.5 stop bit mode has seen almost no use during last few decades. Even if the receiver gets the framing error part right, it would still need to correctly synchronize to the continuous stream of bits.I have actually encountered a system once which was unable to synchronize. It had good clock accuracy and good signal integrity (which are indeed unrelated), but had continuous stream of data with no idle periods, and data which either did not either generate framing errors, or if it did, resynchronization never succeeded. It simply did not work, at all, because of the power sequencing order. Solution was to deliberately force idle periods in the data.Because 99.9% of actual UART usage patterns include idle periods longer than a character at least now and then, any other way of resynchronization gets very little testing, and especially USB-UART adapters are rushed to the market with not much testing.

author: Peabody
author_rank: Super Contributor
timestamp: November 24, 2022, 04:56:07 am
content: In my experience, if both sides are using approximately the same baud rate, there is no loss of sync. If you feed a square wave into RxD it will report a continuous stream of the character "U", or 0x55, at 8N1. The "A" in UART is for asynchronous. When it detects the beginning of the start bit, it then waits for 1.5 bit periods to sample the first data bit, then waits one additional bit period for each of the following data bits and the stop bit so as to read the data line in the middle of the bit period. If the stop bit is high, as it should be, it immediately transfers the received byte into the buffer and triggers the interrupt to indicate that a byte has been received, and then it starts looking for the next start bit. So the send and receive clocks can actually be 5% off, or maybe even more, and it will still work perfectly. There's no need for delays unless the receiving end can't process the data fast enough to keep up, but of course that has nothing to do with the UART.I once designed ML routines to enable the C64 to perform continous simultaneous transmit and receive at 2400 baud, so as to emulate the 6551 UART chip which it didn't have, and my code just duplicated the 6551 datasheet explanation, as described above. It worked fine. I suspect modern UART peripherals still do it exactly the same way.

author: BrianHG
author_rank: Super Contributor
timestamp: November 24, 2022, 07:22:32 am
content: Once any side begins a transmission after a dead period greater than the character length, that transmitter automatically becomes the master reference character clock at the fall of it's TXD output. The receive side tracks and corrects it's bit clock alignment so when it transmits a character, it is both bit synchronous and also byte synchronous.So long as the bit size and stop bit are properly set, a continuous transmission of 0x55 would never mess up as the receiver hardware would always keep bit count from the beginning never loosing count even if your software misses a character interrupt. The only time this would fail is if you are software enabling / disabling / re-setting up your UART.Here I made my own synchronous UART written in verilog and I demonstrated a simulation of how I re-adapt to slight baud errors and maintain a bit and character lock when transmitting if I first received a com event from an external host.See sim illustration here:https://www.eevblog.com/forum/fpga/verilog-rs232-uart-and-rs232-debugger-source-code-and-educational-tutorial/My first illustration shows how even with a huge baud rate error, my oversampling via source system clock will re-align it's character transmitter bit-stream to the incoming received clock. If you understand verilog, my source code is well documented and illustrates how this clock re-alignment is done, but it basically boils down to an oversampling routine bit re-alignment to the drop of the incoming RXD input.

author: m k
author_rank: Super Contributor
timestamp: November 24, 2022, 12:39:33 pm
content: Quote from: skysurf76 on November 19, 2022, 07:19:38 pmAnd so, does it matter?Since beginning is not important the count can't be either.And for all other cases the data is always correct, until it drifts and resyncs.

author: David Hess
author_rank: Super Contributor
timestamp: November 24, 2022, 02:33:01 pm
content: Quote from: CaptDon on November 22, 2022, 01:57:07 amEven in the 1970s, I saw RS-232 systems run continuously for hours at a time without loss of synchronization. In the 1980s and 1990s, I had systems that ran for days from 2400 to 115200 baud without ever a problem. Clock drift in asynchronous systems has been a solved problem for a long time.Quote from: langwadt on November 21, 2022, 12:47:05 amI do not know exactly what logic is used, but I have to assume that the start bit is typically sampled multiple times to find the middle since the hardware for this is already present. They are *not* going to rely on just edge detection because it would be particularly error prone. At 8 time oversampling, maybe they wait for 3 out of 4 start bit samples. None of the various UART datasheets I have studied discuss this particular aspect.

author: BrianHG
author_rank: Super Contributor
timestamp: November 24, 2022, 05:19:41 pm
content: Quote from: David Hess on November 24, 2022, 02:33:01 pmOversampling was for RX timing optimization. The RS232/485 line driver transceiver was responsible for correcting edge noise. The 'maybe they wait for 3 out of 4 start bit samples' was used for aligning to a superior sweet sample point withing each transmitted bit being received. If you look at my posted sync UART sim with it's bit rate error tolerance, you will notice that instead of a simple 3-4 clocks, I actually work out the number of sub-sample clocks necessary for centering the sampling of each bit as my UART always samples at the full system clock, even if it is 50MHz or eve >100MHz.

author: langwadt
author_rank: Super Contributor
timestamp: November 24, 2022, 05:25:08 pm
content: Quote from: David Hess on November 24, 2022, 02:33:01 pmyou have to detect the edge to find the center of the bits. So from idle, when you samples goes from 1 to 0 you know there is ~1.5 bit time to the center of the first data bit, the every 1 bit time, you are at the center at the next bit, once you get to the stop bit you start looking for a start bit again. That is where a slow receiver might get in trouble with a continuous stream of data, because the start bit might start before it is looking at the stop bit

author: BrianHG
author_rank: Super Contributor
timestamp: November 24, 2022, 05:34:41 pm
content: LOL,my UART receiver operates only at 1/2 stop bit. Anything larger and it will re-align to the source in real time.However, I do realize this discussion is about industry standard UARTs, though I cannot discount that modern MCU UARTs don't do the same thing, IE have the same tolerance to ignore the stop bit in the RX while only placing the selected stop-bits in their TX output.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 24, 2022, 05:38:30 pm
content: Again, clock drift is a different thing. When you detect a start bit, you can also zero the reference time, this is why clock drift in itself is not a problem, unless the error is very large.The question here is, can you detect what is a start bit? The consequence of this question is much larger: if you can't, not only does clock drift become a problem, but byte separation will, too: you may be treating start and stop bits as actual data, along with the data bits that belong to the different byte. Some of these misinterpretations generate framing errors, but then again, if you detect one, the receiver only knows something is wrong. The question still is, what is the correct start bit?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, and it's worth noting different hardware might behave differently, some may have better detection mechanisms than others, e.g. try different synchronization points until framing errors disappear. Simplest implementations might just look for idle followed by transition, which is very flaky in noisy conditions or with the wrong (tx first) power-up sequence.The problem just seems rare because usually serial communication uses idle periods. Even if you have a longer burst of continuous data, it's still often preceded by some kind of higher level hand-shaking part.

author: BrianHG
author_rank: Super Contributor
timestamp: November 24, 2022, 05:59:17 pm
content: Quote from: Siwastaja on November 24, 2022, 05:38:30 pmYou 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.

author: Peabody
author_rank: Super Contributor
timestamp: November 24, 2022, 07:55:57 pm
content: Quote from: Siwastaja on November 24, 2022, 05:38:30 pmWell 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.

author: westfw
author_rank: Super Contributor
timestamp: November 24, 2022, 11:39:41 pm
content: QuoteI'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!

author: Siwastaja
author_rank: Super Contributor
timestamp: November 25, 2022, 09:46:24 am
content: Quote from: BrianHG on November 24, 2022, 05:59:17 pmYes, 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, andenjoythe 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: November 25, 2022, 09:50:09 am
content: Quote from: Peabody on November 24, 2022, 07:55:57 pmDid 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.

author: westfw
author_rank: Super Contributor
timestamp: November 25, 2022, 10:15:28 am
content: QuoteBTW, 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!

author: Siwastaja
author_rank: Super Contributor
timestamp: November 25, 2022, 10:17:17 am
content: Quote from: westfw on November 25, 2022, 10:15:28 amI 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 beguaranteed, with easily calculated maximum time, instead of "this solution may increase chances of success".

author: Peabody
author_rank: Super Contributor
timestamp: November 25, 2022, 05:15:31 pm
content: 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.

author: BrianHG
author_rank: Super Contributor
timestamp: November 25, 2022, 05:42:01 pm
content: Quote from: Siwastaja on November 25, 2022, 09:46:24 amAlways 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.