asynchronous' and 'synchronous protocols

Thread Starter

MTech1

Joined Feb 15, 2023
161
Hello,

I've came accross the terms 'asynchronous' and 'synchronous' protocols, and I'm trying to understand their meanings in this context. I've noticed that UART is considered an asynchronous protocol, while SPI is synchronous. It appears to be linked to data transmission timing.

Could someone help me to understand what is meant by 'asynchronous' and 'synchronous' when referring to communication protocols?
 

Ian0

Joined Aug 7, 2020
9,785
Synchronous data is sent as two signals (data and clock),and asynchronous data is sent as data only.
In order for asynchronous data to work, sender and receiver must agree beforehand on the baud rate, and a synchronising pulse must be sent to start the transmission (the "start" bit).
For synchronous data, as the clock is transmitted the receiver always knows the data rate.
There are schemes such as Manchester coding whereby the clock and data are combined into one signal.
Asynchronous data is sent from a SCI (Serial Communications Interface), another name for a UART (Universal Asynchronous Receiver and Transmitter)
SPI (serial Peripheral interface) is synchronous. Synchronous peripherals can be simpler as they don't need a clock oscillator.
 

Papabravo

Joined Feb 24, 2006
21,222
A truly synchronous protocol has the identical timing for all of the bits in a frame. Bit synchronization is established by recognizing a "frame preamble" with a fixed pattern, which may or may not include coding violations. Once the preamble is recognized, it establishes byte synchronization for the remainder of the frame. No gaps are allowed between any of the information or check bytes in a frame. In order for the to work in practice a clock signal must be included with the data on transmit and be recovered by the receiver.

In asynchronous communication each byte will establish bit synchronization for one character frame of 10 or 11 bits. There is no limit to the amount of time between frames. Transmit and receive clocks are not required to be identical, but they must be close. 2% is a usual figure quited by the serial interface equipment makers.

In practice SPI and I2C look like they should be synchronous, especially when implemented in hardware. If you read the specifications with care, you realize that maintaining any kind of synchronous behavior is NOT a REQUIREMENT, only a convenience.
 

Thread Starter

MTech1

Joined Feb 15, 2023
161
In order for asynchronous data to work, sender and receiver must agree beforehand on the baud rate,
I think, In asynchronous communication, two devices (let's call them Device A and Device B) must agree on the "baud rate," which is the data transmission speed measured in bits per second (e.g., 9600 bps).

Device A sends data with a "start" bit, and Device B expects to receive data at the same baud rate. If they don't use the same baud rate, communication may fail due to timing mismatches
 

Ian0

Joined Aug 7, 2020
9,785
I think, In asynchronous communication, two devices (let's call them Device A and Device B) must agree on the "baud rate," which is the data transmission speed measured in bits per second (e.g., 9600 bps).

Device A sends data with a "start" bit, and Device B expects to receive data at the same baud rate. If they don't use the same baud rate, communication may fail due to timing mismatches
That's correct.
There are schemes where the receiver measures the length of the first bit it receives assuming it to be the start bit, and sets its baud rate accordingly. That only works well if everyone is using one of the "usual" baud rates: 300, 600, 1200, 2400, etc.
Of course, the first bit it receives could be random noise and from then on it is set to the wrong baud rate.
 

Thread Starter

MTech1

Joined Feb 15, 2023
161
So, in synchronous protocols like SPI, both sender and receiver share the same clock signal. Sender send clock signal to receiver but how does receiver know when to read or send each data bit?
 

Papabravo

Joined Feb 24, 2006
21,222
So, in synchronous protocols like SPI, both sender and receiver share the same clock signal. Sender send clock signal to receiver but how does receiver know when to read or send each data bit?
For SPI it is one of four configuration choices.
 

WBahn

Joined Mar 31, 2012
30,029
So, in synchronous protocols like SPI, both sender and receiver share the same clock signal. Sender send clock signal to receiver but how does receiver know when to read or send each data bit?
They do it as specified by the protocol. That's what a protocol is -- it's a set of rules that both parties agree to abide by.

Different protocols achieve the same goals in different ways. Read up on the protocols you are interested in and see how devices using that protocol do it.
 

Thread Starter

MTech1

Joined Feb 15, 2023
161
Read up on the protocols you are interested in and see how devices using that protocol do it.
As per my understanding, in the SPI protocol, the master sets the timing for the slave. For example, if the master generates clock pulses, and one clock pulse takes 5 microseconds, then the slave should transfer and receive one bit within that 5 microsecond time frame. It's important to ensure clock mode should match on both the master and slave sides to maintain proper communication
 

Papabravo

Joined Feb 24, 2006
21,222
As per my understanding, in the SPI protocol, the master sets the timing for the slave. For example, if the master generates clock pulses, and one clock pulse takes 5 microseconds, then the slave should transfer and receive one bit within that 5 microsecond time frame. It's important to ensure clock mode should match on both the master and slave sides to maintain proper communication
Almost. It is true that both devices must agree on the clock phase and polarity. In SPI the master generates (originates) the SCLK signal. The peripheral device receives the SCLK signal from the master over what is essentially a low impedance "wire" and responds accordingly. There is NO ISSUE of the transmitter and the receiver having independently generated clock signals. There is ONLY one clock signal in an SPI, or I2C system.
 

Ian0

Joined Aug 7, 2020
9,785
As per my understanding, in the SPI protocol, the master sets the timing for the slave. For example, if the master generates clock pulses, and one clock pulse takes 5 microseconds, then the slave should transfer and receive one bit within that 5 microsecond time frame. It's important to ensure clock mode should match on both the master and slave sides to maintain proper communication
It's not so much about timeframes but about edges. Transmitter changes the Data line on one edge of the clock, and receiver latches it in on the other, so that the data is stable when it is read. Two bits set which way round it is, generally called CPHA and CPOL (clock phase and clock polarity).
SPI errors are mainly caused by getting the settings wrong so that the receiver is trying to read the data on the same edge as the transmitter changes it. It works sometimes because of the delays in the system, but not always!
 

MrChips

Joined Oct 2, 2009
30,789
Read the last two post over.
There is only one SCLK source. The master sends SCLK.
It is the SCLK edges that matter, not the clock period. Both rising and falling edges are important. CPHA and CPOL must be set the same on both devices.
 

Thread Starter

MTech1

Joined Feb 15, 2023
161
Read the last two post over.
There is only one SCLK source. The master sends SCLK.
It is the SCLK edges that matter, not the clock period. Both rising and falling edges are important. CPHA and CPOL must be set the same on both devices.
I observe four important aspects of the SPI clock signal:

  1. Clock stays high for a certain duration.
  2. Clock stays low for a certain duration.
  3. The transition from high to low takes a specific amount of time.
  4. The transition from low to high also takes a specific amount of time.

You mean data transfer or reception typically occurs at clock transitions, not when the clock stays high or low in one clock cycle.
 

nsaspook

Joined Aug 27, 2009
13,253
The idle (usually before the device is selected with CS) state (a polarity of a binary signal for logic low/high) of the clock.

https://www.analog.com/en/analog-dialogue/articles/introduction-to-spi-interface.html
Clock Polarity and Clock Phase
In SPI, the main can select the clock polarity and clock phase. The CPOL bit sets the polarity of the clock signal during the idle state. The idle state is defined as the period when CS is high and transitioning to low at the start of the transmission and when CS is low and transitioning to high at the end of the transmission. The CPHA bit selects the clock phase. Depending on the CPHA bit, the rising or falling clock edge is used to sample and/or shift the data. The main must select the clock polarity and clock phase, as per the requirement of the subnode. Depending on the CPOL and CPHA bit selection, four SPI modes are available. Table 1 shows the four SPI modes.
1696174343255.png
Figure 2. SPI Mode 0, CPOL = 0, CPHA = 0: CLK idle state = low, data sampled on rising edge and shifted on falling edge.

1696174439399.png
Figure 4. SPI Mode 3, CPOL = 1, CPHA = 1: CLK idle state = high, data sampled on the falling edge and shifted on the rising edge.
 

Ian0

Joined Aug 7, 2020
9,785
I observe four important aspects of the SPI clock signal:

  1. Clock stays high for a certain duration.
  2. Clock stays low for a certain duration.
  3. The transition from high to low takes a specific amount of time.
  4. The transition from low to high also takes a specific amount of time.

You mean data transfer or reception typically occurs at clock transitions, not when the clock stays high or low in one clock cycle.
I'd say that the transitions (in either direction) take an unknown amount of time, not a specific amount of time. That's why we read the data on the clock edge to the one where the data changes state, because we don't quite know exactly when the data will change state, except that it will be a little after the clock edge.
 

MrChips

Joined Oct 2, 2009
30,789
I observe four important aspects of the SPI clock signal:

  1. Clock stays high for a certain duration.
  2. Clock stays low for a certain duration.
  3. The transition from high to low takes a specific amount of time.
  4. The transition from low to high also takes a specific amount of time.

You mean data transfer or reception typically occurs at clock transitions, not when the clock stays high or low in one clock cycle.
Ignore the length of time the clock stays low or high, except for certain criteria which I will explain below.

Also, ignore the length of the transition takes. In reality, the moment that the transition takes effect is infinitesimally short.

In situations such as this one, what is critically important is what is know as setup and hold time.

1696177103886.png
In order to have reliable operation, the data must be stable prior to the clock edge. This is the setup up time tsu. Similarly, the data must be stable for a length of time following the clock edge. This is the hold time th. This should make proper sense since obviously you don’t want the data to be changing at anytime during the occurrence of the clock pulse.

By the same token, you don’t want the clock to be changing state if the above conditions are not satisfied. Hence we make sure that clock low and high durations are longer than the above activity.
 

nsaspook

Joined Aug 27, 2009
13,253
I suspect that even after being shown the details there is still a surprised pikachu face.
Very likely. Without the proper background foundation (indicated because of the level of questions) of basic sequential logic (for asynchronous' and synchronous digital logic) , digital communications and design, the word patterns we often use are interpreted as gibberish even if individual words are understood. My method for today's learners is to try to be a bit more visual and multi-media because it seems few want to study textual information in detail anymore and do the work of writing things out by hand to reinforce learning.
 

MrChips

Joined Oct 2, 2009
30,789
For the TS to grasp the concepts of data synchronization, it would be educational to visit the concept of eye-patterns in ultra-high speed communications systems.

When high speed data is viewed on an oscilloscope, the image might look like this, called an eye pattern.

IMG_0975.jpeg
As you can see, there is a very narrow window of opportunity where the data must be sampled in order to maximize the signal-to-noise ratio, and that is at the dead center of the eye. This is where you want the clock transition to occur.
 

WBahn

Joined Mar 31, 2012
30,029
I observe four important aspects of the SPI clock signal:

  1. Clock stays high for a certain duration.
  2. Clock stays low for a certain duration.
  3. The transition from high to low takes a specific amount of time.
  4. The transition from low to high also takes a specific amount of time.

You mean data transfer or reception typically occurs at clock transitions, not when the clock stays high or low in one clock cycle.
How is it that you are "observing" these aspects?

If I am designing an SPI interface, I need to know what I can count on from the other end of the connection. Instead of having to track down the person that designed that part and ask them, I instead rely on them having designed it to a certain specification. That spec is a set of parameters that, if both ends are in compliance with, both ends can communicate.

Even if my SPI interface could work with a 10 GHz clock rate, it is unreasonable to expect that everyone else's can, too. It is not too unreasonable, however, for me to expect some minimum speed that any compliant interface can work at. So a standard (and there is no SPI standard, which complicates things) would put a minimum value on the clock HI and LO durations. As long as your system has longer durations, you're good.

Similarly, many logic circuits cannot tolerate the circuit spending too much time at intermediate voltages (and hence undefined logic levels), but instead require that transitions between logic levels must take more than some maximum amount of time. As long as your system transitions faster than that, you're good.
 
Top