communication protocols in embedded systems

Discussion in 'Embedded Systems and Microcontrollers' started by Parth786, Oct 22, 2017.

  1. Parth786

    Thread Starter Active Member

    Jun 19, 2017
    642
    45
    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?
     
  2. Papabravo

    Expert

    Feb 24, 2006
    12,164
    2,673
    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.
     
  3. Parth786

    Thread Starter Active Member

    Jun 19, 2017
    642
    45
    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?.
     
  4. Papabravo

    Expert

    Feb 24, 2006
    12,164
    2,673
    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.
     
    Parth786 likes this.
  5. MaxHeadRoom

    Expert

    Jul 18, 2013
    18,221
    5,592
    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.
     
    Parth786 likes this.
  6. Parth786

    Thread Starter Active Member

    Jun 19, 2017
    642
    45
    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 ?
     
  7. Papabravo

    Expert

    Feb 24, 2006
    12,164
    2,673
    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.
     
    Parth786 likes this.
  8. MaxHeadRoom

    Expert

    Jul 18, 2013
    18,221
    5,592
  9. GopherT

    AAC Fanatic!

    Nov 23, 2012
    7,983
    6,779

    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.
     
    spinnaker and Parth786 like this.
  10. be80be

    AAC Fanatic!

    Jul 5, 2008
    1,784
    350
    You are not asking the right thing
     
  11. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    5,783
    6,514
    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
    [​IMG]
    Status display (Idiot Lights, all GREEN is good) for a IHC Ion Source controller.

    [​IMG]
    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.o_O

    [​IMG]

    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.
    Code (C):
    1.  
    2. if (PIR1bits.RCIF) { // is data from host light link via RS-232 port
    3. link_count++;
    4. ibs_stream_file = RCREG;
    5. if (RCSTAbits.OERR || RCSTAbits.FERR) {
    6. ibs_stream_file = 0x00; // nulls for data on errors
    7. RCSTAbits.CREN = FALSE; // clear overrun
    8. RCSTAbits.CREN = TRUE; // re-enable
    9. if (c_error++>MAX_C_ERROR)
    10. c_error = 0;
    11. } else {
    12. if (!V.config)
    13. TXREG = ibs_stream_file; // echo
    14. }
    15. if (ibs_stream_file == 0x00) // this is bad data in the stream
    16. ibs_d = 1; // reset at bad data
    17. if (ibs_stream_file == CONFIG_CHAR) { // search for configuration stream
    18. if (++config_found > CONFIG_REPEATS) {
    19. V.config = TRUE; //
    20. config_found = 0;
    21. }
    22. } else {
    23. config_found = 0;
    24. }
    25. if (ibs_stream_file & 0x80) { // stream data bit 7 set
    26. ibs_data[ibs_d] = ibs_stream_file & 0x3f;
    27. ibs_d++; // index to store the data stream
    28. if (ibs_d > MAX_DATA)
    29. ibs_d = 1; // reset on overrun
    30. } else { // stream codes for source parameters
    31. ibs_d = 1;
    32. ihc_d = ((ibs_data[1]&0x0f) << 6)+(ibs_data[2]); // convert the 10 bit data from the stream
    33. ibs_data[0] = ibs_stream_file; // store the stream code
    34. // parse the stream codes
    35. switch (ibs_stream_file_prev) {
    36. case IHC_CODE0: // extraction regulation
    37. if (++ihc_count[0] > IHC_SAMPLES)
    38. V.ihc_data0 = FALSE; // in range preset to false
    39. if ((ihc_d > IHC_CODE0L) && (ihc_d < IHC_CODE0H)) {
    40. V.ihc_data0 = TRUE; // set range code to true
    41. ihc_count[0] = 0;
    42. ihc_d_roc = ihc_d - ihc_d_prev;
    43. V.ihc_d_abs = (ihc_d_roc < 0 ? (-ihc_d_roc) : ihc_d_roc);
    44. ihc_d_prev = ihc_d;
    45. if ((V.ihc_d_abs <= V.fine)) {
    46. if (V.inreg) FINE_REG = LEDON; // regulation in tight mode
    47. V.stable = TRUE;
    48. if (!glitch_count)
    49. GLITCH_ERROR = LEDOFF;
    50. } else {
    51. FINE_REG = LEDOFF; // not in fine regulation
    52. }
    53. } else {
    54. FINE_REG = LEDOFF; // not in fine regulation
    55. }
    56. break;
    57.  
    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.
     
    Parth786 likes this.
  12. Parth786

    Thread Starter Active Member

    Jun 19, 2017
    642
    45
  13. Picbuster

    Well-Known Member

    Dec 2, 2013
    913
    119
    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
     
  14. spinnaker

    AAC Fanatic!

    Oct 29, 2009
    7,815
    3,703
    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?
     
  15. WBahn

    Moderator

    Mar 31, 2012
    24,237
    7,552
    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.
     
    Parth786, absf and nsaspook like this.
  16. philba

    Active Member

    Aug 17, 2017
    959
    303
    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.
     
  17. Picbuster

    Well-Known Member

    Dec 2, 2013
    913
    119
    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
     
Loading...