Hello,
I am learning about different communication protocols and i would just want some clarity on the term protocol. I 've seen this question all over but yet one thing does not seem to make sense.

The term protocol i do understand, it is a set of rules, an arrangement of agreements on how things are suppose to happen. This does make sense, for example SPI is a communication protocol, where one "rule" is how the MASTER/SLAVE relationship is made up, another "rule" is that they share the same clock signal making it a synchronous form of communication etc. I mean protocol is not a bound term to a specific tech-thing, but is more of a general term to me.

And i figure, even for SPI, obviously there has to be some adapted hardware to make this possible, as well as software. (You can't just make a wish and there you go)

So, reading on about UART first thing that pops up is, that it is a circuit, whether it be a stand-alone IC or part of another circuit. It explains on hardware level how it works and that's it. That it uses certain hardware for allowing a type of communication is more or less obvious to me. Actually, UART is the only communication-type i can wrap my head around, everything seems logical.

Now, what i don't understand, is that everywhere they distinguish the two: "UART is not a protocol but a piece of hardware, while SPI is a communication protocol"

So what i am wondering:

UART also has to follow a certain "protocol" in terms of how the communication is setup to happen? So there has to be some form of protocol?

And how come SPI does not imply to a certain piece of hardware, is it possible to implement it "universally" in most systems with a processor and GPIO's?

Appreciate any answers.

 

hi,
UART also has to follow a certain "protocol" in terms of how the communication is setup to happen? So there has to be some form of protocol?

https://circuitdigest.com/article/rs232-serial-communication-protocol-basics-specifications

 

One problem you’ll run into in working out what is going on with communications protocols is trying to apply definitions strictly. Practical communications blurs the lines in any taxonomy or model. The OSI network model, for example, describes seven layers but in practical models those layers are often conflated with more than one in a subsystem of an implementation.

For serial standards, the term protocol will have to be understood in the context in which it is used. Some protocols don’t care about the physical layer aspects and are abstracted as a set of rules for establishing, maintaining, and possibly insuring data integrity. Some will reach down into the physical demanding certain connectors, pin outs, and voltage levels.

In the strictest technical sense, you will find the various standards from places like the IEEE and ITU carefully scope and define what the numbered standard means. If you are talking about some particular numbered standard, the documentation is authoritative.

In real world use, parts of standards are often used without other parts, and things are named for convenience ignoring the technical aspects.

The OSI model is useful to understand how this can be so, if you study it a bit and see how the parts interact you will see why sometimes things get called by a name that’s not really right but that thing donated a part of its de jury standard into the de facto implementation we deal with in “real life“.

 

A protocol is just an agreement between a receiver and a transmitter on the meaning of signals they exchange. It has the same meaning in a diplomatic sense. It is an agreement between two countries about what their communications with each other mean. A protocol can exist in an abstract form completely disassociated from any physical realization.

When it comes to implementation it should be self evident that the hardware used to implement a protocol does not need to be unique. In other words there are multiple ways to realize the hardware required for the implementation of the protocol. Similarly there is no requirement for there to be a software component to a protocol. Some protocols are realized in hardware alone with no software component. Other protocols are software only and require no hardware for their implementation. An API is a good example of a software protocol that requires no additional hardware to implement other than the machine the software is running on. Lastly there are protocols that require a mix of dedicated hardware and software to make a functional system.

To answer the rhetorical question: SPI and I2C as well as many other protocols can indeed be implemented universally in a processor with GPIOs. In my younger days we used to call it "bit banging": loosely defined as using the equivalent of GPIOs to effect the transfer of information.

 

hi,
UART also has to follow a certain "protocol" in terms of how the communication is setup to happen? So there has to be some form of protocol?

https://circuitdigest.com/article/rs232-serial-communication-protocol-basics-specifications

Thanks! this website had a lot of info

 

One problem you’ll run into in working out what is going on with communications protocols is trying to apply definitions strictly. Practical communications blurs the lines in any taxonomy or model. The OSI network model, for example, describes seven layers but in practical models those layers are often conflated with more than one in a subsystem of an implementation.

For serial standards, the term protocol will have to be understood in the context in which it is used. Some protocols don’t care about the physical layer aspects and are abstracted as a set of rules for establishing, maintaining, and possibly insuring data integrity. Some will reach down into the physical demanding certain connectors, pin outs, and voltage levels.

In the strictest technical sense, you will find the various standards from places like the IEEE and ITU carefully scope and define what the numbered standard means. If you are talking about some particular numbered standard, the documentation is authoritative.

In real world use, parts of standards are often used without other parts, and things are named for convenience ignoring the technical aspects.

The OSI model is useful to understand how this can be so, if you study it a bit and see how the parts interact you will see why sometimes things get called by a name that’s not really right but that thing donated a part of its de jury standard into the de facto implementation we deal with in “real life“.

Yes i'm starting to realize this. Blurry is an understatement, i will check those out and hopefully not turn crazy.

Thanks

 

To over simplify; a protocol is a collection of rules that describe how something will work. So a communication protocol is a collection of rules that define how communication will occur. In reality, how strictly those rules are followed can vary.

 

A protocol is just an agreement between a receiver and a transmitter on the meaning of signals they exchange. It has the same meaning in a diplomatic sense. It is an agreement between two countries about what their communications with each other mean. A protocol can exist in an abstract form completely disassociated from any physical realization.

When it comes to implementation it should be self evident that the hardware used to implement a protocol does not need to be unique. In other words there are multiple ways to realize the hardware required for the implementation of the protocol. Similarly there is no requirement for there to be a software component to a protocol. Some protocols are realized in hardware alone with no software component. Other protocols are software only and require no hardware for their implementation. An API is a good example of a software protocol that requires no additional hardware to implement other than the machine the software is running on. Lastly there are protocols that require a mix of dedicated hardware and software to make a functional system.

To answer the rhetorical question: SPI and I2C as well as many other protocols can indeed be implemented universally in a processor with GPIOs. In my younger days we used to call it "bit banging": loosely defined as using the equivalent of GPIOs to effect the transfer of information.

I see, i've heard bit-banging before. I'll check that out, maybe i should experiment a little with that and see if i can get to the bottom with it.

On another note when i look at different microcontrollers, SPI is labeled on specific pins, meaning that there is a certain hardware- adaption to use the protocol. Difference between SPI and UART seems to be that SPI is integrated in terms of hardware, which maybe is why UART is referred to as an individual piece.

Thanks

 

I've always thought that the protocol is more referring to the organization of the data transfer itself, not the hardware used.
For instance, RS485 is not the protocol, but MODBUS running over the RS485 is.
RS485 can transport MODBUS or just plain ASCII serial or even a series of pulses with data encoded in frequency or PWM.....
And MODBUS could be implemented via fiber optics or radio.
But, as you say, it does get a bit blurry.

 

I've always thought that the protocol is more referring to the organization of the data transfer itself, not the hardware used.
For instance, RS485 is not the protocol, but MODBUS running over the RS485 is.
RS485 can transport MODBUS or just plain ASCII serial or even a series of pulses with data encoded in frequency or PWM.....
And MODBUS could be implemented via fiber optics or radio.
But, as you say, it does get a bit blurry.

There will always be something that is "strictly correct" but two things confuse the conversation: ignorance and informality.

People who work in a direct and practical way with communications equipment, that is, who specify components and connect them together, are often ignorant of the underlying details, including protocols themselves, and will call something by a name that doesn't really belong but is the vernacular for their industry.

For example, an "RJ45 connector" isn't "really" a thing. RJ45s is a registered jack wiring standard for 8P8C modular connectors. Because those 8P8C connectors were most often seen wired for RJ45S, the name, once a strict technical term, became the vernacular for the connector, pin out notwithstanding.

Similarly, terms like RS232 and RS485 will mean, in a given context, whatever is "normal" up and down the protocol stack to regular, practical users. In this case, most are ignorant of the distinctions and some speak about these things with informal shortcuts not because they don't know the difference but because it would be tedious to specify when it is understood that many interlocking parts are implied, and, in any case, they would likely confuse the people around them if they tried to use the right terminology.

 

I've always thought that the protocol is more referring to the organization of the data transfer itself, not the hardware used.
For instance, RS485 is not the protocol, but MODBUS running over the RS485 is.
RS485 can transport MODBUS or just plain ASCII serial or even a series of pulses with data encoded in frequency or PWM.....
And MODBUS could be implemented via fiber optics or radio.
But, as you say, it does get a bit blurry.

Haha indeed, here is a link that describes a difference between RS485 and RS232 (referred to as protocols). So there is actually adapted hardware to this as well, for example they mention drivers which is used to give a certain voltage as signal, as well as receivers.
If you are interested: https://circuitdigest.com/article/key-differences-between-rs-485-and-rs-232-serial-protocols