Uart/Usart

[for_the_buzz]

Can any1 explain the exact difference between UART and USART for me please. (in simple terms pls)

Thanks

[Gnome]

Hi,
And welcome to CTH.

Sorry I can't but this may be of some sense to you ( Not Me ( Well not all of it )) HERE (http://botbuilder.org/archive/index.php/t-2421.html)

[for_the_buzz]

HI Gnome

Thanks for your reply and link to the info.Unfortunately I stiil have no idea as 2 the differences. Its worded fairly technical for me to understand as im only starting to study PC stuff.Anyway thanks again and any other info found 4 me is gr8fully appreciated.

[sho-dan]

Google this line "explain the exact difference between UART and USART" without the qoutes. Hope this helps.

btw. for_the_buzz, welcome to CTH.

[for_the_buzz]

Thanks Sho-Dan

Ill look into that now n let u know how I get on.Thanks so much for your reply folks.Much appreciated

[for_the_buzz]

well it looks to me like the answer is somehing like UART is for just serial interface control while USART is for the Serialisation of "Parallel" data But still has the exact logic of the USART. anyway thats all i can make of it really.

:-) :-) :-)

[z1p]

Both serialize data to be sent. The difference between the two is how the data transmission is coordinated between the two ends.

With a UART each ends uses its own clock to control the rate the data is transmitted. This is the mode commonly used to connect dumb terminals and other simple serial devices. The problem with this type of connection is a problem with clocking on one end can disrupt the connection and it only works over short distances.

With a USART both end uses a common clock, this basically [prevents] issues caused by differences in clock rate and allows for a greater distance between endpoints.

Today, you'll find that most serial ICs support both modes of operation.

I personally prefer the more generic term 'serial controller', though now that could include USB controllers.

[oracle128]

UART is Asynchronous, USART is Synchronous. That appears to be the only difference. From Wikipedia:The word "asynchronous" indicates that UARTs recover character timing information from the data stream, using designated "start" and "stop" bits to indicate the framing of each character. In synchronous transmission, the clock data is recovered separately from the data stream and no start/stop bits are used. This improves the efficiency of transmission on suitable channels; more of the bits sent are data. An asynchronous transmission sends nothing over the interconnection when the transmitting device has nothing to send; but a synchronous interface must send "pad" characters to maintain synchronism between the receiver and transmitter. The usual filler is the ASCII "SYN" character. This may be done automatically by the transmitting device.

USART chips have both synchronous and asynchronous modes.
If that's still too technical an explanation, I think it's fairly safe to say you don't need to know the difference.

[z1p]

UART is Asynchronous, USART is Synchronous. That appears to be the only difference. From Wikipedia:
If that's still too technical an explanation, I think it's fairly safe to say you don't need to know the difference.

Once again wikipedia is providing info that is not completely accurate. There are several ways to sync the clocks, deriving the clock from the data at one end is only one way.

None of the various protocols I've worked with used ASCII SYN as the sync character, It seems like someone may have made an assumption that since it was an ASCII SYN character, it must be used for synchronizing serial links.

[for_the_buzz]

Thanks a mill for your replys folks. Z1P your first line in your post "Both serialize data to be sent. The difference between the two is how the data transmission is coordinated between the two ends" seems like this is the exact ans im looking for. So yur a gem. Nice 1. and oracle128 I needed to find an answer for college and wasnt getting much help from anywhere else.Just because someone doesnt understand something straight away doesnt mean they will never understand.If u dont ask you will never know.Just needed some1 to word it in a way I could get into my head and understand. <Z1P> but every1 who posted I do appreciate. Also had a look at wikipedia but as is said above its not always accurate. Its know to have incorrect info.
Buzz

[oracle128]

I needed to find an answer for college and wasnt getting much help from anywhere else.Just because someone doesnt understand something straight away doesnt mean they will never understand.If u dont ask you will never knowIsn't that what text books and lecturers/tutors are for? That's why I assumed you wouldn't need to know, because you hadn't utilized those resources instead.

I also verified the Wikipedia info before posting it. Wikipedia is hardly ever itself wrong, the problem more often than not is bad sources (like this one (http://www.freebsd.org/doc/en_US.ISO8859-1/articles/serial-uart/index.html) or this one (http://www.mr.inf.tu-dresden.de/lehre/ws06/em-sys/msp430/ag_12.pdf)); so if there's an answer it gives that you don't agree with, don't play the "Wikipedia is unreliable!" card, take the issue up with the sources instead.

z1p, also note how WP states how SYN is "the usual filler", it doesn't say that it always or must be that.

[for_the_buzz]

I have Txt books but dont go into it very much and as for my tutor well im doing an online course and asked my tutor via email but the college is crap and havent replied to me in 4 days.thats why i put the question here.
also i read alot about it but just couldnt understand it the way it was worded on pages frm the net.Thats why I was asking here to explain it 2 me in simple terms so i could understand Ja know. Thanks again

[z1p]

Isn't that what text books and lecturers/tutors are for? That's why I assumed you wouldn't need to know, because you hadn't utilized those resources instead.

I also verified the Wikipedia info before posting it. Wikipedia is hardly ever itself wrong, the problem more often than not is bad sources (like this one (http://www.freebsd.org/doc/en_US.ISO8859-1/articles/serial-uart/index.html) or this one (http://www.mr.inf.tu-dresden.de/lehre/ws06/em-sys/msp430/ag_12.pdf)); so if there's an answer it gives that you don't agree with, don't play the "Wikipedia is unreliable!" card, take the issue up with the sources instead.

z1p, also note how WP states how SYN is "the usual filler", it doesn't say that it always or must be that.

Hmm interesting that I didn't see issues in either of your 'bad sources'. neither said that the clock was always derived from the data signal, nor did I see either of them mention the ASCII SYN character.

And as I said I never saw or heard if it being used, in my 8+ years of serial communication development.

And in my opinion wikipedia does have a tendency to be technically inaccurate. For general information its fine, but if you are looking for exact information, especially on tech topics, it falls short.

[oracle128]

A typical UART frame is shown in Figure 1. It comprises a Start bit, 8 data bits, and a Stop bit. Other variants are also possible in RS-232 applications - the data packet could be 5, 6, or 7 bits long, there could be 2 Stop bits, and a Parity bit could be inserted between the data packet and the Stop bit for rudimentary error detection.For this reason, the operator should send a continuous
burst of ASCII SYN characters
...
SYN
LTRS
use for fill if necessary
Asynchronous transmission allows data to be transmitted without the sender having to send a clock signal to the receiver. Instead, the sender and receiver must agree on timing parameters in advance and special bits are added to each word which are used to synchronize the sending and receiving units.
When a word is given to the UART for Asynchronous transmissions, a bit called the "Start Bit" is added to the beginning of each word that is to be transmitted.
...
When the receiver has received all of the bits in the data word, it may check for the Parity Bits (both sender and receiver must agree on whether a Parity Bit is to be used), and then the receiver looks for a Stop Bit. If the Stop Bit does not appear when it is supposed to, the UART considers the entire word to be garbled and will report a Framing Error to the host processor when the data word is read.
Synchronous signaling dispenses with framing bits, but you have to
know where a character starts. There's a character called "SYN" that is
sent repeatedly for long enough so that the receiver can lock up. Nine
is usually enough. The receiver starts anywhere and decodes 8 bits to
form a character. If that is not SYN, it slips a bit and does it again.
When the decoded character is SYN, the receiver adjusts its clock rate
to match the transmitted clock and continues doing that throughout the
transmission. The transmitter sends SYNs whenever it has no data.SYNCHRONOUS MODE: The synchronization of messages is carried out by a special Synchronization Character Code (SYN) transmitted at the beginning of a block of characters.

I don't know why you've never seen one that uses SYN, when it's clearly the most prominent choice for the start bit. All of the sources also make it perfectly clear that a normal device expects timing in the frame, not anywhere else. I know that whenever I used UARTs at uni, they required timing signals in the data stream, and they all used SYN. My lecturer also made no mention of timing being required anywhere else, and he's been an electronics engineer for about 30 years. Of course that doesn't mean that every single UART on the planet has to follow that, there's absolutely nothing stopping anyone from making one that doesn't follow that schema. These are quite obviously the exception and not the rule. It's like saying "cars aren't meant to go on water" - true, you would think, but the existence of some million-dollar car models that actually can travel on water should not be used as evidence to prove that person wrong.

[z1p]

I don't know why you've never seen one that uses SYN, when it's clearly the most prominent choice for the start bit. All of the sources also make it perfectly clear that a normal device expects timing in the frame, not anywhere else. I know that whenever I used UARTs at uni, they required timing signals in the data stream, and they all used SYN. My lecturer also made no mention of timing being required anywhere else, and he's been an electronics engineer for about 30 years. Of course that doesn't mean that every single UART on the planet has to follow that, there's absolutely nothing stopping anyone from making one that doesn't follow that schema. These are quite obviously the exception and not the rule. It's like saying "cars aren't meant to go on water" - true, you would think, but the existence of some million-dollar car models that actually can travel on water should not be used as evidence to prove that person wrong.
I should know better,but I just can't help myself....


Obviously, you got so caught up in trying to prove me wrong you misspoke. Since we were talking about the ASCII SYN character (a byte) it definitely can't be the most prominent choice for the start bit.

Since quotes 1 and 3 have nothing to do with either the idle character used or methods of supplying a common clock in synchronous mode, I'll ignore them.

Now item #5, You happened to omit the references to the SYN register in that document. The reason for the SYN register is so you can load the SYN character that you need. So it appears that the reference to the SYN character in this doc is referring to the character that is loaded in the SYN register not ASCII SYN.

Now #4 is a thread in a forum, again not the most reliable source, just look at the cr** in this thread. Again, you chose to only grab a tidbit that you thought supported you. You apparently didn't take the time to read and comprehend the thread, which was discussing RTTY signals. Since RTTY uses Baudet encoded data, it obviously isn't using ASCII SYN as its idle character.

Lastly, #2 which is the most interesting and by far the most technical. Why don't we look at your quotes from there in context.

The operation of the carrier and autostart gates in RTTY asynchronous mode has been described
previously. While the false-alarm rate using only the carrier gate can be rather high, the false-alarm
rate using the autostart gate is much lower. For this reason, the operator should send a continuous
burst of ASCII SYN characters (which are translated to Baudot LTRS characters) in RTTY
asynchronous mode, or wait a couple of seconds in RTTY synchronous mode, when beginning
transmission to allow a receiver known to be using the autostart function to be unblocked. The
autostart gate is designed for long periods of inactivity, such as when the system is waiting for a
selective call and it doesn’t matter if a few characters are lost at the beginning of transmission.
During a continuous period of activity, the autostart gate has only marginal usefulness. Notice translating the ASCII SYN for transmission. This seems to be talking about an operator hitting the SYN button on a dumb terminal. Not quite the same as ASCII SYN being sent as the idle character.

When
transmitting in synchronous mode, the transmitter sends an idle character (LTRS) if the transmit
buffer is emptyNote LTRS not ASCII SYNif no characters remain to be transmitted, the
two-character sync codeword RQ-a is transmittedagain not ASCII SYNThe encoders also provide idle fill, in order to provide continuous timing in
synchronous modes - LTRS in the RTTY encoder, RQ-a in the SITOR encoder.again your source doesn't say anything about ASCII SYN.

Now if you had made a reference to ISO standard 1745, which defined data communication between IT systems you would have been onto to something as it specifies ASCII SYN as the idle character.

So it appears there are various idle character depending on your encoding. I still never saw ASCII SYN used, but I never worked on communication between IT systems so that could be why.

[oracle128]

Obviously, you got so caught up in trying to prove me wrong you misspoke. Since we were talking about the ASCII SYN character (a byte) it definitely can't be the most prominent choice for the start bit.Correct, thanks for noting my mistake, I did type in a hurry.
Now #4 is a thread in a forum, again not the most reliable source, just look at the cr** in this thread. Again, you chose to only grab a tidbit that you thought supported you. You apparently didn't take the time to read and comprehend the thread, which was discussing RTTY signals. Since RTTY uses Baudet encoded data, it obviously isn't using ASCII SYN as its idle character.So what you're saying is, forum threads are always wrong. Except for when it's you. Isn't that a double standard?
Note LTRS not ASCII SYNNoted. Note that LTRS is the Baudot equivalent of ASCII SYN. That's like saying they don't use ASCII SYN because, technically, they're sent as electrical signals, which aren't ASCII characters. Equivalent means they are the same for all intents and purposes.
again your source doesn't say anything about ASCII SYN.Note again that LTRS is the same as SYN.
Now if you had made a reference to ISO standard 1745, which defined data communication between IT systems you would have been onto to something as it specifies ASCII SYN as the idle character.

So it appears there are various idle character depending on your encoding. I still never saw ASCII SYN used, but I never worked on communication between IT systems so that could be why.Thanks for that info. I admit I was incorrect in that my knowledge of electronics is based on pure IT usage.

[z1p]

Correct, thanks for noting my mistake, I did type in a hurry.
So what you're saying is, forum threads are always wrong. Except for when it's you. Isn't that a double standard?
No, I included myself in that statement. Forums threads have inaccuracies as they are limited by the participants knowledge and experience. It is also colored by they perception of what is being asked.

Noted. Note that LTRS is the Baudot equivalent of ASCII SYN. That's like saying they don't use ASCII SYN because, technically, they're sent as electrical signals, which aren't ASCII characters. Equivalent means they are the same for all intents and purposes.
Note again that LTRS is the same as SYN.
Thanks for that info. I admit I was incorrect in that my knowledge of electronics is based on pure IT usage.Yes the intent and purpose of ASCII SYN and Baudot LTRS in this topic is the same, use as an idle character in a serial data link. However, to say that ASCII SYN is the idle character when Baudot LTRS is being encoded onto the wire is wrong. If the other end was looking for ASCII SYN to sync up on, they would never sync. As a bit pattern they are different and it is the bit pattern that defines the idle character.

[Snurfen]

What a great thread.
I have printed post 16 and will be mounting it in a gilt frame in my downstairs kharzi.
I can die a happy man at last!

[oracle128]

What a great thread.
I have printed post 16 and will be mounting it in a gilt frame in my downstairs kharzi.
I can die a happy man at last!Why's that? Because I acknowledged that my knowledge of the subject is limited to the industry upon which this forum is based? Or because I admitted wrongdoing despite the logical fallacy? When you print off my admission, make sure you note that it was gathered from "CyberTechHelp.com, the 'Computer Help Community'".

[Snurfen]

Nope, because you admitted you were wrong!

[oracle128]

Nope, because you admitted you were wrong!In otherwords, option 2 above.