How to choose I2C speed - Page 1
Forum section: electronics / beginners

author: Nikos A.
author_rank: Regular Contributor
timestamp: July 02, 2021, 12:15:58 pm
content: Hi I am using th nRF52840 development board and I will connect an IMU and fuel gauge on the I2C bus. The IMU (BMX160) supports both standard mode (100kHz) and fast mode (400kHz) and extended mode (1MHz) while the fuel gauge supports standard mode and fast modesFrom the I2C driver of nRF52840 I can select between 100kHz, 250kHz and 400kHzHow do I know what frequency do I need? What are the factors and how can I calculate that?Fuel gaugehttps://www.ti.com/lit/ds/symlink/bq27421-g1.pdf?ts=1625211098870&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FBQ27421-G1IMUhttps://www.mouser.com/pdfdocs/BST-BMX160-DS000-11.pdfThanksNick

author: rstofer
author_rank: Super Contributor
timestamp: July 02, 2021, 03:28:01 pm
content: In terms of the fuel gauge, how fast can it possibly change? How often do you plan to poll it? I would expect 100 kHz to be more than adequate.As to the IMU, the same questions apply and they are application specific. Rotating the screen on a cell phone doesn't require high speed I2C. Controlling a drone might.I would start with 100 kHz and see how it works out with the idea in mind that I can always kick it up to 400 kHz.If I really wanted 1 MHz for the IMU, I might use two separate I2C channels. It looks to me like you can have as many as 3 channels. But I didn't spend any time with the datasheet.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 03, 2021, 07:26:56 am
content: Well, for example, assuming you want to read out accelerometer and gyro out of the BMX160 in a burst read, including the slave address, that would be 8 + 6 * 16 bits = 104 bits. Add ACK bit for each 8 bits, that's 13 bits more, 117 bits total. Start and stop conditions take some 1 bits worth of time as well, so we are roughly at 120 symbols.At 100ksymbols/s, communicating 120 symbols takes (120 symbols)/(100000 symbols/s) = 1.2 milliseconds.This sets the hard maximum poll rate at 833Hz. In reality, you would add significant dead zones (of no communication) between accesses, and have to poll the battery gauge at some point as well, although that can be done very rarely like once a second. So maybe you would poll the IMU data at 500Hz max. Which is enough for many purposes but not necessarily all.Redo the math if you want to read out more than just those registers.So all in all, if you are building a very highly dynamic angular tracking system for example for a VR headset, you would like to have quicker update rate from the IMU than that, and if you chose to update at 1kHz then 100kHz I2C rate clearly isn't enough, but 400kHz would be already more than enough.Personally, I prefer SPI for IMUs. I like the robustness a hardware flow control signal offers by resetting the communication state for each transaction, I like to sidestep the unreliable and complex I2C peripherals of the microcontrollers whenever possible, and also like the max clock rate of 10MHz for BMX*** for example, compared to max 1MHz for I2C, although the latter is enough for 99.9% of cases. But this is just a personal preference whenever SPI is available.

author: Nikos A.
author_rank: Regular Contributor
timestamp: July 04, 2021, 03:14:53 pm
content: Thank you both for your answers!!@Siwastaja that was exactly what I needed!! 100kHz bus is more than enough for my case, I will poll the fuel gauge at 1Hz while the IMU at 100HzBy the way, what is your favorite 6-axis or 9-axis IMU? I found recently this 6-axis IMU by Boschhttps://www.bosch-sensortec.com/products/smart-sensors/bhi260ab/#softwarethat is recommended for low power applications and also it has an embedded software for sensor fussing. I'm thinking about giving this IMU a try.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: July 04, 2021, 03:23:13 pm
content: The main factors for determining the maximum speed on the I2C bus are bus capacitance and the strength of the pull-up resistors. The passive pull-up resistors are a mayor bottleneck for the I2C bus speed.I2C is not a good fit for long cables because it increases the capacitance of the bus significantly. You should always verify the rise time of SDA and SCL with an oscilloscope in your particular situation.

author: JustMeHere
author_rank: Frequent Contributor
timestamp: July 04, 2021, 05:06:35 pm
content: When you hit 1MHz you will start to see problems loop area regarding noise. You will need to pay attention to the return path and, ideally, use a 4 layer board. You should twist wires, or at least keep the return wire next to the signal wire. You will need to minimize loop area. This can cause some real annoying noise an any analogue sensors in your system.

author: rstofer
author_rank: Super Contributor
timestamp: July 04, 2021, 06:58:40 pm
content: While you're looking at bus speed and I2C versus SPI, consider how much or how little the CPU needs to get involved with the transfer. It's pretty easy to poll the devices but there has to be some CPU cycles left for the application.Does the CPU have DMA capabilities? Does SPI take advantage of them? How about I2C?You would set up a generic command string and point the DMA to it and then just hand control over to the SPI or I2C peripheral. The return data should also go straight to memory via DMA.These drivers are not trivial to write.Consider the 600 MHz Teensy 4.1https://www.pjrc.com/store/teensy41.htmlI haven't really looked at this but both protocols work with DMAhttps://www.pjrc.com/teensy/IMXRT1060RM_rev2.pdf

author: cortex_m0
author_rank: Regular Contributor
timestamp: July 05, 2021, 02:26:21 am
content: My preferred algorithm for selecting the bus speed: use the highest speed you can, which in this case would be 400 kHz.This is because I usually care about power/battery life, and the MCU will use more power the more the serial modules are active. Let's imagine this MCU uses 1mA while executing I2C transactions, and 1uA while fully in sleep state, and you're doing a transaction that takes 120 I2C clock cycles at 10ms polling rate. I did not look at the documentation to estimate if this is reasonable for the NRF52840.With these assumptions, at 100kHz, the average current would be ~121uA. At 400kHz the average current would be ~31uA.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 06, 2021, 09:13:18 am
content: DMA with I2C is not always functional at all in many microcontrollers. You'll figure that when actually writing code, it's hard to realize earlier when just going through the datasheet. Some I2C peripherals require significant CPU work and more than one interrupt per byte.Regarding CPU sleeping for low power consumption, often 100kHz vs. 400kHz won't make a difference because you end up sleeping between all byte transactions anyway; you would need even higher data rate so you could try to process multiple bytes / whatever is causing those interrupts anyway without exiting the interrupt, i.e., poll for shorter times than interrupt enter and exit latency. Even 1MHz I2C usually doesn't hit that use case. So you waste power, or hope the DMA can handle the burst read operation.BMX IMUs have FIFOs which are useful if you require post-processing of multiple samples beyond what the internal filters would do for you yet you don't need the real-time performance. So you can burst read multiple samples at once.Bosch Sensortec IMUs like BMX160 are fine otherwise except you can't buy them for the next year or two, it seems the current component crisis is hitting Bosch Sensortec maybe more than other IMU manufacturers. On technical side, I have used BMX055 and BMX160 and had zero technical problems with them. Their gyros are quite good for the price, accelerometers have a lot of offset and temperature-related drift. Magnetometers are darn hard to use properly to high accuracy regardless of the chip manufacturer.

author: cortex_m0
author_rank: Regular Contributor
timestamp: July 06, 2021, 11:13:53 pm
content: Quote from: Siwastaja on July 06, 2021, 09:13:18 amI wasn't making any assumptions about core being awake in my previous post. It takes power to keep the I2C, DMA and the necessary clock domains going during an I2C transaction. The faster those can be shut down, the less power the MCU uses - and the thing setting that timing is the slow bit rate of I2C.Again, I don't know much about the NRF52, so maybe it's very efficient when the core is slept. But the numbers I gave in my earlier reply are roughly what I measured when I was working on I2C firmware for an Atmel MCU some years ago.