I have a bit of a weird question, and I’d really like to hear how someone with practical experience would approach it.

Suppose you have a temperature sensor that can provide temperature data through four interfaces: UART, SPI, I2C, and CAN. You need to connect it to an MCU and simply read the room temperature. Since all four interfaces can give you the same temperature value, which one would you actually choose, and more importantly, what would be your reason for rejecting the others?

Personally, I would probably remove CAN first, but my reason is not very strong. I mainly associate CAN with automotive and distributed/robust communication, so it feels unnecessary for a simple temperature sensor connected directly to an MCU. But I’m not sure if that is a good technical reason.

Then between SPI, UART, and I2C, I would probably remove SPI because it generally needs more signal lines than I2C, especially when multiple devices are involved. That leaves UART and I2C.

If saving pins is the main concern, I might choose UART because it only needs TX and RX, whereas I2C needs SDA and SCL. But I also know this is probably oversimplifying the decision

how would you make this decision. Which interface would you choose in this particular situation, and what would be your reason for rejecting the other three?

 

My first consideration would be what type of sensor and its location in relation to the MCU.

Then does it need two-way communication/handshaking?

In the case of a remote wired sensor does it autonomously send data or does it need to be polled?

Is there more than one sensor sitting on the same wired path?

Is a wired sensor’s environment noisy?

So, the choice of the most appropriate protocol may be dictated by the type of sensor, data transmission path and electrical environment. There will be one protocol that stands out as the most suitable.

 

what environment? what temperature range? what accuracy?
for simple DIY automation and easy connectivity i would use ESP01 (Really small and has WiFi), and connect to it one or several DS18B20.

 

I will choose the easiest. UART.

 

My question was more about the interface selection itself, rather than choosing the sensor.

Let’s assume:

• the sensor is very close to the MCU, on the same PCB
• only one sensor is connected
• normal indoor environment, say 0–50°C
• around ±1°C accuracy is sufficient
• the sensor supports UART, SPI, I2C and CAN equally well
• I only need to read the temperature periodically, say once per second
• no special need for long-distance communication or multiple nodes
• cost and availability are not part of the decision

If all four interfaces can provide the same temperature data under these conditions, which one would you choose and why would you reject the other three?

 

My question was more about the interface selection itself, rather than choosing the sensor.

Let’s assume:

• the sensor is very close to the MCU, on the same PCB
• only one sensor is connected
• normal indoor environment, say 0–50°C
• around ±1°C accuracy is sufficient
• the sensor supports UART, SPI, I2C and CAN equally well
• I only need to read the temperature periodically, say once per second
• no special need for long-distance communication or multiple nodes
• cost and availability are not part of the decision

If all four interfaces can provide the same temperature data under these conditions, which one would you choose and why would you reject the other three?

Based on the additional information you have provided, my choice is I2C.

 

Based on the additional information you have provided, my choice is I2C.

What makes you choose I2C in this particular case? I'm more interested in the reasoning behind the choice and why you would reject UART, SPI and CAN under these assumptions.

For example, is it mainly because of pin count, addressing, bus capability, simplicity, or something else?

 

What makes you choose I2C in this particular case? I'm more interested in the reasoning behind the choice and why you would reject UART, SPI and CAN under these assumptions.

For example, is it mainly because of pin count, addressing, bus capability, simplicity, or something else?

I am not aware of any temperature sensor that provides those four communications protocol.
CAN rejected for being too complex.
UART rejected for intended for duplex communication.
I2C selected over SPI for being simpler. Both are designed for short haul on-board PCB device interfaces.

One protocol which is a serious contender is 1-Wire, for example, Maxim DS18B20.
https://lastminuteengineers.com/ds18b20-arduino-tutorial/

 

I have a bit of a weird question, and I’d really like to hear how someone with practical experience would approach it.

Suppose you have a temperature sensor that can provide temperature data through four interfaces: UART, SPI, I2C, and CAN.

If there's a sensor like that, can you tell me which one it is?

If I were to solve such an (unlikely) problem, I would replace the sensor. The DS1820 was designed to address pin-count economy.

I even enjoyed developing the full required library for a PIC micro, 18F family IIRC.

 

I am not aware of any temperature sensor that provides those four communications protocol.

I wasn't referring to an actual temperature sensor that supports all four interfaces. I was intentionally making up a hypothetical situation. The idea was: suppose, just for the sake of discussion, that I have a temperature sensor and it is available with UART, SPI, I2C and CAN versions. All four can provide the same temperature data.

For the other points, I’m still not completely clear on the reasoning.

CAN rejected for being too complex.

When you say CAN is rejected because it is "too complex", do you mean the hardware side, software/protocol side, or both? What specifically makes it unnecessarily complex for this particular application?

UART rejected for intended for duplex communication

For UART, I’m not sure I understand the duplex point. If the temperature sensor only needs to send the temperature to the MCU, couldn't we simply connect the sensor TX to the MCU RX and leave the other direction unused? In that case, what specifically makes UART unsuitable?

I2C selected over SPI for being simpler. Both are designed for short haul on-board PCB device interfaces.

And for I2C being simpler than SPI, could you explain what you mean by simpler? Is it because of fewer pins, bus architecture, software implementation, wiring, or something else?

 

There is also 1-Wire.

Edit: as @MrChips has already pointed out. Sorry.

 

There is more than one way to skin a cat.
There is the dependable LM35 linear temperature sensor.
If you want to avoid having to use an ADC input, you can use a thermistor and a timing capacitor on a single GPIO pin.

 

There is the dependable LM35 linear temperature sensor.
If you want to avoid having to use an ADC input, you can use a thermistor and a timing capacitor on a single GPIO pin

I think my question may have been misunderstood.

I was not really asking how to measure temperature or which temperature sensor to use. The temperature sensor was just a hypothetical example.

What I'm trying to understand is the decision-making process when, hypothetically, the same sensor is available with UART, SPI, I2C and CAN interfaces.

For example, if you choose I2C, what specific characteristics make I2C the better choice in that situation, and what specific characteristics make you reject UART, SPI and CAN?

I'm trying to understand the reasoning behind both the selection and the rejection of the alternatives.

 

I think my question may have been misunderstood.

I was not really asking how to measure temperature or which temperature sensor to use. The temperature sensor was just a hypothetical example.

What I'm trying to understand is the decision-making process when, hypothetically, the same sensor is available with UART, SPI, I2C and CAN interfaces.

For example, if you choose I2C, what specific characteristics make I2C the better choice in that situation, and what specific characteristics make you reject UART, SPI and CAN?

I'm trying to understand the reasoning behind both the selection and the rejection of the alternatives.

For me, overall system cost and parts availability -- while achieving the project specification -- is the prime decision driver.

 

if you insist of having external sensor, so be it, in that case nothing beats single wire which is what DS18B20 does. that is one IO per sensor. and that single wire can be used to read bunch of sensors... for example if you read 8 sensors using one wire, that is 1/8 of an I/O per sensor.
the other question is if anything already on board has internal temperature sensor. nowadays one finds temperature sensor in just about everything. in this case zero I/Os need to be dedicated to read temperature.

 

Please don't consider the actual temperature sensor, LM35, DS18B20, internal MCU sensor, cost, availability, etc. Those are not what I'm trying to compare.

Assume your company gives you a temperature sensor module, and that module is available with UART, SPI, I2C or CAN interfaces. All four options have the same cost and availability, meet the same temperature range and accuracy requirements, and the sensor is located close to the MCU on the same PCB.

Your job is simply to read the temperature once every second.

Now you have to make an engineering decision and select one interface.

What I'm trying to understand is:

What would make you say "I'll use I2C" rather than UART/SPI/CAN?

And after selecting I2C, what specific technical disadvantage of UART, SPI and CAN would make you reject each of them in this particular situation?

I'm not looking for one "correct" answer. I want to understand the thought process and trade-offs an experienced engineer considers when several interfaces can technically accomplish the same task.

For example, if your choice is I2C, I'd really appreciate an explanation in this form:

I choose I2C because ___.
I reject UART because ___.
I reject SPI because ___.
I reject CAN because ___.

That would help me understand the reasoning much better.

 

Assume your company gives you a temperature sensor module, and that module is available with UART, SPI, I2C or CAN interfaces.

This is a hypothetical that (almost?) never happens.

In any case, you use the interface that makes sense for the system into which it is being integrated.

 

In that case, my choice would be bluetooth.

 

In that case, my choice would be bluetooth.

Zigbee is self-meshing.

 

you're still solving the practical problem of how you would implement the temperature measurement, whereas my question was more about the hypothetical interface-selection decision.

In my first post, I had already shared my own thought process and the way I would narrow down the options. What I was hoping to get from the discussion was how other experienced engineers would approach the same hypothetical situation and, more importantly, the reasoning behind accepting one interface and rejecting the others.

So Bluetooth/Zigbee may be good practical solutions, but that's slightly different from what I was trying to ask.