Protocols in embedded systems is used to transmit/ Receive data from one device to another device. I2C, UART, CAN, SPI These are common protocols used in embedded systems. I need help to understand specific use of protocols. I don't understand when I use them. I searched it on internet. I also read in book but I don't understand How to select select specific protocols.

Can anyone tell me, when do we use I2C or UART or CAN or SPI ? I just want to know which protocol we will use and when we will need it?

 

The generic answer is that we use an available protocol when we need it. If we need something that does not exist we invent it. This is not really a deep philosophical question. You see a device that you need in your system, it uses protocol "blyfix", so we see if we can implement protocol "blyfix". It is really that simple.

 

The generic answer is that we use an available protocol when we need it. If we need something that does not exist we invent it. This is not really a deep philosophical question. You see a device that you need in your system, it uses protocol "blyfix", so we see if we can implement protocol "blyfix". It is really that simple.

Can you help me with some example

Microcontroller -------------- LCD
Microcontroller -------------- RTC
Microcontroller -------------- Desktop Computer
Microcontroller -------------- Memory
Microcontroller -------------- Wifi module

How do you think ? How will you select specific protocols for above example?.

 

Can you help me with some example

Microcontroller -------------- LCD
Microcontroller -------------- RTC
Microcontroller -------------- Desktop Computer
Microcontroller -------------- Memory
Microcontroller -------------- Wifi module

How do you think ? How will you select specific protocols for above example?.

I will look at the datasheet to see what is required by each of those modules. The choice is seldom independent of the datasheets. What I mean is that you cannot force a protocol on an existing device. If there is no existing protocol then you can adapt or invent one.

 

It also depends on required speed of transmission, environment it is operating in, what is currently in use for devices in place, what modules are available for controlling processor.
Multi-drop or single etc.
Max.

 

Now I can say selection is depend on two points. First, architecture of device and Second, transmission speed of data. But still have confuse. I can find the datasheet what decide in datasheet to select protocol and how it is depend upon the speed of transmission ?

 

Now I can say selection is depend on two points. First, architecture of device and Second, transmission speed of data. But still have confuse. I can find the datasheet what decide in datasheet to select protocol and how it is depend upon the speed of transmission ?

The datasheet will tell you if the device supports one or more protocols. If it doesn't support the one you want, you toss the datasheet and keep looking. As far as transmission speed is concerned you don't always go for the maximum speed. In CAN for example you get to trade off speed for cable length. You might want to 500 meters at 1 Mbps, but you can't so you don't. You back off to 125kbps and you ger your 500 meters of cable distance with some headroom to spare.

 

Modbus using RS485 is one that is used quite a bit in industrial systems.
http://www.yoctopuce.com/EN/article/a-quick-tutorial-on-rs485-and-modbus
Max.

 

Now I can say selection is depend on two points. First, architecture of device and Second, transmission speed of data. But still have confuse. I can find the datasheet what decide in datasheet to select protocol and how it is depend upon the speed of transmission ?

It’s like visiting the United Nations. You have to ask the two devices which languages they speak. If they don’t speak a common language, you’ll need a translator. Since it is easier to work without translators, you search for other devices that can speak with your second device.

Sometimes you are stuck on one particular device that speaks language A, you then have to search for a second divide that speaks that language. If you are stuck with both devices and they don’t have a common language, then you’ll need a translator.

 

You are not asking the right thing

 

A communications protocol is more like a set of rules defined to allow information transfer on an interface. I2C, UART, CAN, SPI are at the hardware end (CAN is a hardware to packet level protocol, "nice") of the protocol levels. If the design is completely original then you have your choice of hardware interfaces and software protocols with peers but usually you must consider the device interfaces that already exist on hardware.

A simple example: You need to design a small embedded system that interfaces with a existing light-link based UART interface so you obviously would need to use the interface of a UART on the new device to make it work with the correct physical hardware interfaces.

Project: https://github.com/nsaspook/ihc_mon

Status display (Idiot Lights, all GREEN is good) for a IHC Ion Source controller.

So you build your embedded system with the correct hardware layer and now you need to program and/or design the proper software protocol layer(s) to communicate with existing devices. If you're lucky you have a detailed document about and/or ready to use software library for this software protocol but if you're not like I was on this project you might need to reverse engineer how it works with something like a stream capture of the data. That's when the fun begins.

Controller UART data stream analyst
https://github.com/nsaspook/ihc_mon/blob/master/ibsdata.h
https://github.com/nsaspook/ihc_mon/blob/master/ibs_code.txt
https://github.com/nsaspook/ihc_mon/blob/master/ibs_code_sort.txt

Program data stream handler/parser code fragment that understands the communications protocol sent on the UART port.

if (PIR1bits.RCIF) { // is data from host light link via RS-232 port
link_count++;
ibs_stream_file = RCREG;
if (RCSTAbits.OERR || RCSTAbits.FERR) {
ibs_stream_file = 0x00; // nulls for data on errors
RCSTAbits.CREN = FALSE; // clear overrun
RCSTAbits.CREN = TRUE; // re-enable
if (c_error++>MAX_C_ERROR)
c_error = 0;
} else {
if (!V.config)
TXREG = ibs_stream_file; // echo
}
if (ibs_stream_file == 0x00) // this is bad data in the stream
ibs_d = 1; // reset at bad data
if (ibs_stream_file == CONFIG_CHAR) { // search for configuration stream
if (++config_found > CONFIG_REPEATS) {
V.config = TRUE; //
config_found = 0;
}
} else {
config_found = 0;
}
if (ibs_stream_file & 0x80) { // stream data bit 7 set
ibs_data[ibs_d] = ibs_stream_file & 0x3f;
ibs_d++; // index to store the data stream
if (ibs_d > MAX_DATA)
ibs_d = 1; // reset on overrun
} else { // stream codes for source parameters
ibs_d = 1;
ihc_d = ((ibs_data[1]&0x0f) << 6)+(ibs_data[2]); // convert the 10 bit data from the stream
ibs_data[0] = ibs_stream_file; // store the stream code
// parse the stream codes
switch (ibs_stream_file_prev) {
case IHC_CODE0: // extraction regulation
if (++ihc_count[0] > IHC_SAMPLES)
V.ihc_data0 = FALSE; // in range preset to false
if ((ihc_d > IHC_CODE0L) && (ihc_d < IHC_CODE0H)) {
V.ihc_data0 = TRUE; // set range code to true
ihc_count[0] = 0;
ihc_d_roc = ihc_d - ihc_d_prev;
V.ihc_d_abs = (ihc_d_roc < 0 ? (-ihc_d_roc) : ihc_d_roc);
ihc_d_prev = ihc_d;
if ((V.ihc_d_abs <= V.fine)) {
if (V.inreg) FINE_REG = LEDON; // regulation in tight mode
V.stable = TRUE;
if (!glitch_count)
GLITCH_ERROR = LEDOFF;
} else {
FINE_REG = LEDOFF; // not in fine regulation
}
} else {
FINE_REG = LEDOFF; // not in fine regulation
}
break;

Once you understand the total communication protocol requirements then you can program that into the controller. Deciding on the interface is just one aspect of a communications protocol with the upper software layers usually being the ones that will give you the most trouble.

 

You are not asking the right thing

What is your point? What are the right things ?

Thanks to @nsaspook, @Papabravo @GopherT, @MaxHeadRoom @be80be Tanks to all of you

 

Protocols in embedded systems is used to transmit/ Receive data from one device to another device. I2C, UART, CAN, SPI These are common protocols used in embedded systems. I need help to understand specific use of protocols. I don't understand when I use them. I searched it on internet. I also read in book but I don't understand How to select select specific protocols.

Can anyone tell me, when do we use I2C or UART or CAN or SPI ? I just want to know which protocol we will use and when we will need it?

First of all you have to identify what you want and why you want to transfer bytes.
eq you want to display information to calibrate a running system. Now you know that it has to be quick but display a temperature of one ton of steel show every 15 minutes.
Environment hot/ cold/ wet / dry / dusty / chemicals/ (strong) electrostatic fields or a combination.
Information over a distance cable/ fibre /water or air integrity tests needed?
An answer is possible if you define what you want not just a display or memory but all the rubbish around it.( as stated before).

Picbuster

 

The TS does bring up a very good subject. But the question should be extended to why so many protocols? I can understand they can have different capabilities. An easy one is One-wire. Because, well it communicates over one wire! But are there any over laps? That is one or more protocols with the same capabilities?

Is there any place that has a one stop shopping for all of the protocols to show the capabilities of each?

 

The TS does bring up a very good subject. But the question should be extended to why so many protocols? I can understand they can have different capabilities. An easy one is One-wire. Because, well it communicates over one wire! But are there any over laps? That is one or more protocols with the same capabilities?

Is there any place that has a one stop shopping for all of the protocols to show the capabilities of each?

Probably not a one-stop shop -- just too many of them out there for that.

Most protocols have some kind of history that drove their initial development. Often it was because they needed something from an interface that other options didn't have. Sometimes it grew out of a simple ad-hoc protocol that someone threw together to get something up and running and then another project needed something and they just grabbed it because it was familiar and "good enough" and that continued and eventually an entire line of products grew around that interface and as soon as anyone else wanted to talk to those products you now had a need to make it an actual protocol. Sometimes it was because one that would work would have required a license. Sometimes it was because they wanted their own protocol and then it gained a following and became widespread (GPIB started out as HPIB, for instance).

Another reason that it is hard to find a comparison chart amongst the various protocols, particularly the embedded end of the spectrum, is because the performance is often dictated not by the official protocol documents, but by the hardware it is employed on. So you see SPI, for instance, running at tens of megahertz. You can get away with stuff like this because these protocols are so often used in closed designs that do not need to plug and play with other systems that are nominally using the same protocols.

 

I agree pretty much with what has been said but the question of protocols isn't really something to worry about, especially at the front end of the process.

Generally, either the host system or external device(s) you require will define the protocol(s) you need to use. Some devices support multiple protocols (SPI and I2C, for example) so you pick the best match for your host system and application needs. Sometimes the decision is driven by what libraries are available. Sometimes it's driven by the developer's experience. I don't think the design process should start out with "what protocol should we use". Typically, the functional requirements define what components are needed and then you start looking at protocols.

For example, say you want to build a system that drives hundreds of LEDs from your favorite microcontroller. You don't start with protocol. You look for driver ICs that will meet your needs. When you have winnowed the choices down to a few, you might look at the protocols they require though it's highly likely that any device is supportable on any modern microcontroller.

 

The TS does bring up a very good subject. But the question should be extended to why so many protocols? I can understand they can have different capabilities. An easy one is One-wire. Because, well it communicates over one wire! But are there any over laps? That is one or more protocols with the same capabilities?

Is there any place that has a one stop shopping for all of the protocols to show the capabilities of each?

An other reason is to protect your sales your equipment is using a different protocol.
Forced customer to buy extensions and extra's from that supplier. (eq see variation at the OsI layer (2) 3 and up modbus and canbus)
Picbuster