There can be no academic debate on which device and its communication scheme is best until all the facts are on the table.

 

I am going with the I2C group.

Simple and works fine.

Ron

 

The problem is you don't understand the nature of your own question.

Engineering is always a matter of tradeoffs.

A good engineer chooses the solution that satisfies the specification in the most efficient way, all the while balancing multiple conflicting criteria.

You are asking, for one single isolated factor -- a comm channel -- which is the best and why?

There is no answer without a system spec.

A crappy wet-behind-the-ears college graduate may choose UART, simply because that is what he knows and doesn't want to learn the intricacies of I2C, but that would be the wrong reason.

No one here worth his salary will choose any of your options "just because" given your limited and incomplete spec.

 

I was approaching the question more from a learning perspective than from a real project-design perspective.

I was hoping to get a little more specific explanation of the trade-offs between the interfaces, but I don't think I'm getting the kind of explanation I was looking for from this discussion. So rather than keep insisting on the same hypothetical question, I'll leave it here.

Thanks everyone for taking the time to respond.

 

I was approaching the question more from a learning perspective...

And we were trying to teach you.

But you choose to walk away.

 

I’d actually like to continue the discussion because I still feel I haven’t got the answer I was looking for.

My question is not about finding one universally "best" protocol. If I have four available options, my question is simply: what makes you select one of them, what makes you reject the other three, and why?

I gave a hypothetical requirement intentionally because I’m trying to understand the theory and the decision-making process, not solve a particular real-world problem. Obviously, if I had an actual project, I would look at the complete system requirements and consider different solutions accordingly.

A few members have given their preferred choice, such as I2C, but I was hoping to understand the reasoning behind that choice and the specific reasons for rejecting the other options.

So I’m not trying to argue that one protocol is universally better than another. I’m simply trying to understand: if four technically possible options are available, how do you narrow them down to one, and what are the reasons for eliminating the others?

 

I choose the interface that comes with the chip.
For example, HC-05 bluetooth module requires RX/TD UART interface.
nRF24L01 needs SPI.
SHTC3 temperature/RH uses I2C.
There are ST accelerometers that offer I2C/SPI/MIPI.

 

If it's on the same board: I2C or SPI.
If it's a distance away: UART if there is just one sensor, CAN if there is more than one.

Reasons: I2C and SPI cannot transmit over a long distance. Either can support multiple sensors, but I2C can do it with fewer processor pins.
The hardware of a CAN interface can deal with multiple sensors which might try and transmit simultaneously. To do the same thing with a UART would require software to prevent data collisions.

 

So, coming back to my original hypothetical question, I think the answer is that under those assumptions, I could choose UART, SPI or I2C because the sensor is on the same PCB, the distance is short, and all three can provide the same temperature data. There isn't necessarily one universally correct choice.

But if the requirements change, then the choice also changes. My understanding is:

If I need a high-speed connection, I would consider SPI because it provides full-duplex communication.

If I need multiple devices on a short shared bus and want to save MCU pins, I would consider I2C because multiple devices can share the same two bus lines.

If I have a simple point-to-point connection between one device and another, I would consider UART.

And if I have multiple nodes where any node may need to initiate communication, I would consider CAN.

So I think the main thing I was trying to understand is that we don't really select a protocol just because it can transfer the required data. We select it based on the system requirements, and those requirements determine which interfaces make more sense and which ones we can reject.

Is that a fair way to look at it?

 

This is where the human exasperation kicks in. A true human Turing Test.

 

So, coming back to my original hypothetical question, I think the answer is that under those assumptions, I could choose UART, SPI or I2C because the sensor is on the same PCB, the distance is short, and all three can provide the same temperature data. There isn't necessarily one universally correct choice.

But if the requirements change, then the choice also changes. My understanding is:

If I need a high-speed connection, I would consider SPI because it provides full-duplex communication.

If I need multiple devices on a short shared bus and want to save MCU pins, I would consider I2C because multiple devices can share the same two bus lines.

If I have a simple point-to-point connection between one device and another, I would consider UART.

And if I have multiple nodes where any node may need to initiate communication, I would consider CAN.

So I think the main thing I was trying to understand is that we don't really select a protocol just because it can transfer the required data. We select it based on the system requirements, and those requirements determine which interfaces make more sense and which ones we can reject.

Is that a fair way to look at it?

If your sensor is on the same board as the processor and the processor has A/D inputs, use analogue. Your sensor can then be a cheap NTC thermistor and they are cheap as chips ("cheap as French fries" doesn't have same ring to it).

 

We select it based on the system requirements, and those requirements determine which interfaces make more sense and which ones we can reject.

Is that a fair way to look at it?

Maybe. The selection often begins with selecting a device(s) that perform the function at hand. Those devices will then dictate the interface. I know your going the 'hypothetical' route, but that is skewing your quest, and potentially your conclusions. A temp sensor can be a single analog line to wifi. Choose a device and lookup its interface. That's what will drive your design. MCU manufacturers anticipate this by giving an abundance of interface options.

 

So I think the main thing I was trying to understand is that we don't really select a protocol just because it can transfer the required data. We select it based on the system requirements, and those requirements determine which interfaces make more sense and which ones we can reject.

You can come up with any number of hypothetical situations and each will demand a different outcome.
But consider this one. How many applications can you think of where the temperature sensor is on the PCB and not connected via some long cable?

 

You might be asking a general question about which device communication interface is best or preferred?
But think of it from the chip manufacturer's perspective. They are filling a market need in specific market areas, e.g. automotive, aerospace, robotics, smartphone, medical, consumer. etc.

The manufacturer has to set up R & D, production and test facilities with plans to sell a million and more units at less than $1 per unit. There is no financial or marketing advantage to offer different interface options to its customers.