diff bet UART & I2C

Status
Not open for further replies.
UARTS are used for asycronous serial communication. No clock is required and the timing of the bits is determined from the leading edge of each character. A minimal full-duplex interface requires three wires, TxD(Transmit Data), RxD(Receive Data) and Ground. The full duplex means there can be data going in both direction at the same time.

I2C is sycnronous data transfer with a data line and a clock line. It is half duplex, meaning data can only go one way at any given time.
 
adding further,
UART is a point-to-point communication i.e. only two devices talk to each other, u can not connect extra device on the same UART (unless u r using RS485 drivers/lines)!!
I2C gives freedom over that, u can connect as many as 128 devices on the same 2 wire line (with 7-bit address range), saving a lots of wiring for u!!

common use of UART is to talk outside the board using RS232, RS422 etc. drivers,while I2C is used mainly to communicate between the devices on the same board!!

----------------------
https://dharmanitech.blogspot.com
 
Papabravo said:
No clock is required and the timing of the bits is determined from the leading edge of each character.
Click to expand...

I am not sure what you meant by this, I assume you mean that the clock is not part of the communciations protocol such as I2C which uses a clock from DTE to DCE? But just to clarify, a clock is required when using UARTs, whether it be an internal or external clock, it is still used. A PLL is commonly used to sync the clock with the incoming received data.
 
The very name UART, being an Asynchronous communication method, is that it is not SYNCHRONIZED with a clock. Rather, unintelligent UART methods only rely on being set with the same parameters such as baud, parity, and stop bits. Intelligent UARTs(not an official name, just one I use) can look at a frame of data and determine it's parity, baud rate and stop bits by itself, but it's only used in more complex devices.

EDIT: It's also important to mention that the I2C interface supports clock stretching, where devices that need more time to receive and process data can pull the clock line low (due to being designed to be open-drain) to tell the master device that it's not ready. Though I2C can theoretically support 127 devices, your average I2C slave device can't have it's address fully configured,
 
Last edited:

True, it is not synchronized with a clock, and if you look at my post, that was not my point. Just because it's not synced with a clock doesn't mean it doesn't use one. My statement was made for clarification. It was mentioned that UARTs DON'T USE a clock. My point was, they DO use a clock it's just not synced with the data, as the name implies.
 
Uh, no, if the data isn't synchronized with a clock pulse, what's the point of it? A UART only needs to work with 3 lines: Tx, Rx, and ground. The only clock signals involved here are at each device, where they both have to generate a timing signal for internal UART handling. There is NO clock signal connection between the two devices. Also, if you're referring to the clock element of the UART itself, of course it needs a clock, all electronics need a time element to actually progress in execution.
 
Last edited:

I know there is no clock signal between the devices. That's not what I am saying. I am referring to the TX/RX clocks used to clock the bits into the shift registers. If you are talking about a data format of 8,N,1, than the receiving UART somehow has to lock on (and yes synchronize itself) to the incoming data stream. It uses a technique called center-sampling to do this. Depending on how the clock is configured, it will either use the incoming start bit or a PLL to sync the clock with the data stream.
I think you misunderstood my earlier posts. Here's the jist of it:

NO clock signal between devices. Thereby making asynchronous.
LOCAL TX/RX clocks required for shifting data in to, and out of the ports.

You may say at this point, "Well no xxxx". But not knowing the experience of the OP, I wanted to clarify the requirements of the clocks that work locally at the device because of what was said in an earlier post.

If you still disagree, feel free to provide a data sheet of a device you are referring to and I will do the same.
 
rezer said:
A PLL is commonly used to sync the clock with the incoming received data.
Click to expand...

Sorry, but that isn't so - as it's an asyncronous process there's no clock signal to be recovered, so PLL's aren't used - and couldn't be. You use a completely separate clock at the receiving end, which needs to be close enough to remain in sync only for a single word length, as it resyncronises every start bit.
 

Wouldn't a real UART use a Delay-Locked loop to change the phase of the baud rate's internal clock to be aboots 90 (whoops, not 45) degrees out of phase (to facilitate center-sampling), and a Fractional Baud Rate Generator to create the actual baud rate clock?
 
Last edited:

I don't think any do, nor would there be any advantage - there's nothing in the received data to lock to, so why phase lock to a locally generated signal?.
 

Well it depends on the clock speed doesn't it? If the clock speed is x1 with respect to your baud rate, than a PLL would be required for synchronization of the clock to the incoming data stream because there would be no way to use center-sampling. You don't phase-lock to a locally generated signal, you are correct, but you would for the incoming signal. But obviously, if your clock is faster than your baud rate, say x16, than you don't need a PLL. To say that you could not use a PLL is not true. I have experience working on such systems that used a PLL for data sync.

But my point was simply this, a seperate clock is used at the receiving end, just as you said.
 
Last edited:
rezer said:
To say that you could not use a PLL is not true. I have experience working on such systems that used a PLL for
Click to expand...

I didn't say 'could' not, I said 'do' not - it would be a silly way to do it, far easier to use a higher frequency and divide down.

Do you know of any hardware UART's that use a PLL?, presumably if you have experience using such a device, it was built from scratch to overcome a specific problem?. Many of the older UART's don't even have their own clock, you have to provide it, at a multiple of that required.
 


Actually you said PLLs "couldn't be" used. Read your post. And yes, many UARTs don't provide their own clock but I don't know what you mean by "...at a multiple of that required." Multiple of the baud rate?
 
rezer said:
Actually you said PLLs "couldn't be" used. Read your post. And yes, many UARTs don't provide their own clock but I don't know what you mean by "...at a multiple of that required." Multiple of the baud rate?
Click to expand...

Yes, older UARTs used typically a X16 baud clock.

They would start a clock counter at the leading edge of the start bit and re-sample at 8 clocks into the start bit to verify a valid start bit and thereafter would count 16 clock pulse so that subsequent data bits would be sampled at their exact mid-bit time.

After a valid stop bit was detected the counter would reset and wait for another leading edge start signal to start the timing for the next character. Any slight timing error between sender and receiver would only accumulate up to 10 or 11 bit framing cycle as the clock would start afresh with each stop bit. Timing in asynchronous mode can be quite tolerant of slight variation between sender and receiver circuit timing.

I worked on UARTs built with standard 7400 logic chips in the early 70s and the simple design worked very well. When the first LSI uart chips were designed they used the same design principle, not sure about the latest hardware UARTs inbuilt to micro-controllers. Because of the reestablishment of timing with each character in asynchronous circuits there is no need for a synchronous clock recovery system as required for synchronous communication circuits, it's just not needed and would only add expense and board space.

Lefty
 
Last edited:
Yes, I agree. Most UARTS and microcontrollers I have used (current devices) get their clock internally from the system clock. Center-sampling is still used. But I am only familiar with a few of them. I am sure there are other ways of doing it.
 
Last edited:
Status
Not open for further replies.

Similar threads

A
  • Question
ASM: i2c software headache
2 3
Replies
58
Views
9K
augustinetez
A
S
  • Question
uart problem
Replies
1
Views
3K
rjenkinsgb
G
  • Question
PIC16F877AA - NON-CONTACT THERMOMETER
Replies
9
Views
4K
rjenkinsgb
  • Question
UART/CODE problem Oshonsoft
3 4 5
Replies
83
Views
14K
camerart
M
  • Question
TM4C1294 UART interrupt handler registration
Replies
2
Views
4K
allone
A
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…