UART or I2C sensor version?

The tfmini is an IR lidar sensor. There is a UART and an I2C version, quite at the same price.
For my project, I need 2 tfmini hooked up to an Arduino UNO with a +/- 1m cable.
I’ve been doing some tests with 2 tfmini UART versions and it works fine following the example “TFmini_Arduino_SoftwareSerial_Multiple” from
I need to build more occurrences of my UNO with 2 tfminis, and want to try the I2C version of the tfmini.
As I am no specialist of communication protocols, I’d like to know what could be the theoretical pros and cons of using either of these protocols (mostly regarding reliability and the cables lengths, but I might miss some other important criteria).
Thanks a lot!

Hi @od1_fr

On this page, you have a nice comparison of UART, SPI and I2C

I hope it helps :slight_smile:

1 Like

UART is the slower than I2C and SPI as the faster than both.

This is a good article:

1 Like

You beat me to it! lol

1 Like

I did :smiley:

1 Like

It all works out well in the end since we have different sources with the same information. :grinning:

1 Like

I agree :slight_smile: I hope we will soon have these protocols in our Tutorials section!

1 Like

Thanks for you answers!
Speed is not a big criteria for my project. Stability is. If UART is slower, could that mean it’s more stable?

I’ll leave this one for the RoboShop experts, I haven’t had issues with either and like I2C due to only needing 2 wires to communicate.

1 Like

If it is slower, then you can transmit signals more safely to bigger distances. This means you could use longer cables. Also, what is often used to protect the signal is twisting wires and shielded cables.

1 Like

Thanks a lot for your advices @igor_X and @bmoscato ! From what I understand now, UART might be the way to go for my project.
Last thing: I’ve heard bad things about SoftwareSerial in Arduino, which I used in my UART Lidar sketch. Would you worry about it?

What have you heard about it?

Hehe, yes, it ain’t precise statement I concede. That is what I “heard”:

SoftwareSerial is very inefficient, because it disables interrupts for long periods of time. This will interfere with other parts of your sketch, or with other libraries. Since your devices are running at 9600, you could use my NeoSWSerial library. It is much more efficient. Much.

A secondary problem with SoftwareSerial is that it cannot transmit and receive at the same time. So if you send a command to one of the devices, received data will be ignored. NeoSWSerial can TX and RX simultaneously.

Ok :slight_smile: Sounds reasonable :slight_smile:

You can try at least at the beginning with SoftwareSerial and later one if you have issues, try other libraries.

That’s what I’ll do. I’ll also test both versions of the sensor to see which one seems more reliable.

1 Like

Good. If you want, you can share more info about your project and what are you building here :slight_smile:


I’d say to stay away from I2C for 1 meter cables. While I2C is the go-to for most sensors, it is an open drain bus and therefore very sensitive to high capacitance on the bus. A 1 meter cable would add a lot of that and most likely won’t work well for I2C. It does stand for Inter-Integrated Circuit after all (was designed for use on PCBs between chips; see Applications).

UART can be more stable, but only if you use following the RS-232 format (high voltage, negative voltage) or in a differential line format, such as RS-485. TTL UART as is done by most microcontrollers uses VCC & GND (for highs & lows) and without further packaging of the data will be prone to errors too at longer distances.

SPI is my personal favorite. Great for high-speed communication of large amounts of data, especially if your microcontroller has DMA for it and a good buffer size. That being said, long lines will most likely be an issue for fast data rates (“no error” slew rate will suffer/be low).

All in all, all of these can be used with longer cables but the easiest will be UART since you can easily use higher voltage with a voltage translation adapter to help with signal loss (and a bunch of other electrical tricks, too!).

Indeed, SoftwareSerial is pretty inefficient but still works good for most purposes / cases where you have little else going on at the same time. NeoSWSerial is certainly a good alternative if you start having interrupt issues.
If you are curious about other alternatives, there is also AltSoftSerial if that fits with your project.

Looking forward to seeing how your tests go. Let us know! :smiley:



My personal favorite solution (and what I did for a lab temperature/door monitoring project) was to have a microcontroller near the sensors reading them in I2C. This microcontroller than had its UART peripheral interface connected to a TTL UART <> RS-232 which was then wired in the ceiling to the master microcontroller collecting the data from the various nodes.

Nowadays I’d probably just use an XBee, ZigBee or LoRa board at each node and collect data at the base station. Less wiring is always better :stuck_out_tongue:

Of course, whatever you do, if there will be significant noise on your data (or even if there isn’t by design, you never know!), add data correction and code to handle cases where corrupted/bad data is received!

1 Like