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.

 

Reasons: I2C and SPI cannot transmit over a long distance. Either can support multiple sensors, but I2C can do it with fewer processor pins.

Now you just have to convince Lego they made a mistake on the Mindstorms NXT and EV3 line (no idea what Spike used).

Both of those systems use I2C for most of the sensors; certain sensors use just power and a pin for analog input.

Then there is the interesting one of the ultrasonic sensor. See - Lego uses on the NXT and EV3 what are essentially 6P6C RJ-11/12 connectors (they have a right-offset latch - and don't ask me where you can buy the tool to crimp 'em - I've looked; consensus seems to be modding a standard crimp tool).

So with 6 pins on the sensors - things are...fun. I'm still trying to figure out what to do for something I'm making, but I think I have a workable solution. But anyhoo - the pins go something like this for the sensor ports:

1 - Analog Input
2 - Ground
3 - Ground
4 - 4.3 VDC (can be 5V - used for...tada...see next two pins)
5 - SDA
6 - SCL

Pins 5 & 6 might be backwards - I would need to consult the schematics in the dev kit. Regardless, these a both kits that use I2C for communication with -some- of the sensors. Then it get really darn wonky.

For things like the touch sensor and (I think) the light sensor, Pins 1 & 2 suffice...the touch sensor is just a switch, but the light sensor needs power...just like the old RCX system used two wires...

For the ultrasonic sensor? Well - it needs 9 volts! Where does it get it - and what about the light sensor?

Well - I may be wrong about the light sensor - I'm still researching and investigating - but it likely (again) works like the old RCX system - output 9 volts from Pin 1 for 3ms, then switch the pin to an analog input and read the voltage level for 0.1ms - with a capacitor for that brief read period...

As far as I know, Lego never released schematics for the RCX system - so the circuit they used for the RCX that I did find was kinda "speculative" - but seems reasonable. Ultimately, they use a separate digital pin to output 9 volts (direct from the main battery of the system) down the line, then cut that off, flip the digital I/O off, then read the analog pin. One pin, two functions...as long as you don't need crazy read rates.

They probably do the same for the light sensor on the NXT & EV3 - or they power it using the I2C 4.3/5 volts DC.

Back to the ultrasonic sensor - so now you can see where it gets the 9 volts - Pin 1 - and they use a similar (but not quite the same) scheme to both "isolate" and "inject" the 9 volts into that same pin, while keeping the microcontroller "safe".

Everything else on the ultrasonic sensor is done with I2C - but not any I2C...no, instead it's what I term "Lego I2C" (or more accurately, "I2C for the Lego NXT Ultrasonic Sensor").

See - the ultrasonic sensor is "special"...what do I mean by that? Well - for some reason, during a portion of the I2C communication process, you need to wait for a bit between certain transmissions (I suspect it's because of the "pingback" or something - but that's speculation). So the I2C protocol - for that sensor only (as far as I currently understand) - needs that special change. But wait - there's more!

Those two pins can also use regular "I2C" (without the wait period) to communicate with other sensors; those all use standard I2C for communications. But...there's still more! Those two pins also support RS-485 for communications - why? Well - there's a way to connect multiple NXT/EV3 bricks together, so they can talk to each other - an RS-485 network, basically.

To achieve all of this, I2C (standard and Lego-style) and RS-485 is implemented completely in software; it doesn't use any of the hardware interfaces of the microcontroller in the "intelligent brick"; for RS-485, there is some extra hardware components needed (probably for signal cleanup and such?) - but other than that (and I think there are I2C pull-ups in the brick - along with weaker pull-ups in each sensor, as I understand it) - it's all software.

So - why not just use RS-485 for everything? I'm not sure - they could have, but they didn't. I suspect it may have to do with needing extra parts for RS-485, not just a couple of spare pins and a pair of small resistors. Still - given that they weren't limited in sensor housings (in the case of the RCX, they tried to make each sensor fit "inside" a 2x4 brick; touch sensors were in a 2x3 - and there wasn't an ultrasonic sensor - most of the reasoning behind this likely had to do with earlier decisions they made for older systems that ran on an IBM PC and/or Apple IIe back in the 1980s, before the concept of the "intelligent brick") - they could've likely used RS-485 everywhere. But they didn't.

Last fun part? Notice how there are two pins for ground? Both are tied to the same ground - I can't even say it's because of current levels, because even the motors don't use a lot of current - well within I think of the "limit" for the gauge of wire and short distances involved. Furthermore, in the case of the EV3...

Pin 4 is used to identify whether the sensor being used is for the NXT or EV3 - through some kind of scheme...

I don't know if all of these "decisions" had to do with economics, backwards compatibility, or smokin' something...but it all points to a mess, if you want to do what I'm going to attempt - which is a custom "intelligent brick" that can work with every system except "Spike" and "Powered Up". So RCX, Power Functions, NXT, and EV3 - sensors and motors...

They could've save everyone some heartache had they just stuck with a single communications scheme, and even better, a standard connector instead of the funky one they chose (for some reason - right-shifted latch plugs can only barely be found, but left-shifted ones, along with crimpers, are readily available - and normal center ones are everywhere).

Had they just went with bog-standard 8P8C Cat 5 or similar cable, connectors, etc - maybe with ethernet and POE - all of it could've been avoided.

I'd have done that myself for my thing - but then I don't relish having to make a bunch of adapter cables or whatever to connect to existing sensors and motors.

But I guess my ultimate point was that Lego decided to use I2C over 6P6C flat cables, etc - phone connectors - for their robotics systems; distances are not large (I think the longest standard cable is 15cm - but I haven't looked fully) between parts, and you can't "daisy-chain" sensors or motors - so maybe they're "just able" to get away with it, and did it cheaply for better sales margins?

/I keep telling myself I'm having fun with this project...I'm not sure I believe it fully...