1
\$\begingroup\$

Am currently studying 8051 microcontroller and in the course the lecturer told that in communication the frequencies of sender and receiver should be same else they will get different bits of data at different speeds and that would result in either data loss or extra useless data.

In synchronous communication both clock and frequency is same and in asynchronous communication clocks are different.

But as per my understanding the frequency generates the clock , then how are they both different?

\$\endgroup\$
7
  • \$\begingroup\$ Async uses 16x clock to sync on 1st edge \$\endgroup\$
    – Tony Stewart EE75
    Jan 4, 2020 at 5:37
  • \$\begingroup\$ Although there are purely asynchronous systems in theory, almost all systems are fundamental synchronous, it is just that two communicating systems that are each based on a local clock do not have their clocks synchronized even if they might be at the same frequency. They communicate asynchronously by each using synchronous digital logic. \$\endgroup\$
    – George White
    Jan 4, 2020 at 6:08
  • \$\begingroup\$ Google UART. How it works. The 16x sampling like Tony said. The two devices can communicate as long as their internal idea of frequency is not too far off from each other and time is allocated to resynchronize at the end of each byte so timing errors don't accumulate. \$\endgroup\$
    – user57037
    Jan 4, 2020 at 7:21
  • 1
    \$\begingroup\$ Just FYI. I've used devices that employed 64X (and also 4X) over-sampling to perform the same job that is preformed by devices using 16X. So, don't buy the idea of only 16X. (These were standard IC devices and not me using bit-bang.) \$\endgroup\$
    – jonk
    Jan 4, 2020 at 10:03
  • 1
    \$\begingroup\$ Also to the OP. Even if the frequencies of the two MCUs are nominally the same, where they are driven by separate clock sources with the same nameplate frequency, they won't be the same and they will drift around relative to each other. So they are only the same if both driven by the same clock source. \$\endgroup\$
    – jonk
    Jan 4, 2020 at 10:08

1 Answer 1

Reset to default
0
\$\begingroup\$

In synchronous communication, one clock source is used for both transmitter and receiver, with designed propagation times so that transmitter and receiver phases are always correctly aligned.

In asynchronous communication, two independent clock sources of the same nominal frequency are used. The only requirement is that the frequencies be within a tolerance of each other, not that they are identical. For any one word, the phase will be relatively consistent, but it may change between words. It is up to the receiver to handle the changing phase shift, usually by over-sampling and deciding for each word where to put the sampling instant.

\$\endgroup\$
3
  • \$\begingroup\$ Even source synchronous links (such as PCIe and Infiniband) can have local oscillators that are within a nominal tolerance (although they do require other measures such as FIFOs and specialised link control such as the skip ordered set). \$\endgroup\$
    – Peter Smith
    Jan 4, 2020 at 13:54
  • \$\begingroup\$ @PeterSmith not sure what inifiniband is physically (wikipedia not clear), but then how do you go on to classify 'embedded' source clocks as in HDMI and SATA? The receive PLL obviously has to be close to the right frequency, but is actively locked the way that async UARTS are not. Given the apparent state of knowledge of the OP, I think my answer went far enough. \$\endgroup\$
    – Neil_UK
    Jan 4, 2020 at 15:24
  • \$\begingroup\$ It was an observation not a correction and your answer does indeed go far enough but it serves to show that there are some very grey areas in communication links. Infiniband is, in many ways, the fore-runner to PCI express (the state machines are very similar) although it is a fabric (peers only) - I did a lot of it in the early 2000s (I was part of a lot of the working groups at the time). \$\endgroup\$
    – Peter Smith
    Jan 4, 2020 at 15:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.