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?

 

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.

 

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.

 

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

 

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.

 

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?

 

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.

 

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.

 

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

 

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.

 

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!

 

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.

 

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.

 

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.

Figure 2. SPI Mode 0, CPOL = 0, CPHA = 0: CLK idle state = low, data sampled on rising edge and shifted on falling edge.


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.

 

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.

 

I suspect that even after being shown the details there is still a surprised pikachu face.

 

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.


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.

 

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.

 

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.


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.

 

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.