From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple I2C Busses on NI 8452 or 653x

Solved!
Go to solution

Hello,

 

for a current project, I need to communicate with multiple (e.g. 16 or 32) sensors via I2C in parallel. As the sensors are all identical and therefore have identical (unchangeable) I2C addresses, I need to use separate I2C busses. In addition, I would like to communicate in a parallel fashion, i.e. read/write for each bus independently. We use Matlab for high-level experiment control.

 

1) We already have a NI-8452 in the lab that we have used to communicate with a single device successfully. In the manual, a I2C port is mentioned (and can be read out (=0) with the C library). The Manual however never specifies whether there is only a single port or if it is somehow possible to create a second port. On the other hand, since the DIO lines are all software-timed, my assumption would be that this is not possible - then why does the IC2 port exist in the first place?

 

2) Assuming the NI-8452 (or a couple of those in parallel) is not a good option, what would be my best Hardware option from NI for this task?

E.g., would the PXI-6535/6/7 line be suitable for such parallel I2C operation?

 

Thanks in advance for your help,

 

Cheers,

Jakob

0 Kudos
Message 1 of 4
(1,441 Views)
Solution
Accepted by topic author JS_Infineon

Applications requiring access to multiple I2C slaves with the same address use an I2C multiplexer.

 

for example - https://www.analog.com/en/technical-articles/2channel-4channel-pin-selectable-12c-multiplexer.html

 

To answer 1) I2C port input might exist as a placeholder for future devices (if NI plans to manufacture) with more than one I2C port so that they don't need to create new functions or APIs, but just change the implementation under the hood of the driver.

 

2) Buying a lot of 8451/2 to interface with 16 or 32 sensors, in general, is a bad idea just in terms of the cost and complexity (but definitely possible if the application requires). A more advanced option I would suggest buying 6570/1 per 8 devices. In order to test 32 sensors in parallel, you would need 4 qty of 657x instruments.

 

6535 series is a good cost-effective option, but you have to implement additional circuits to implement the open collector outputs and additional software implementation to format the I2C waveforms and decode data.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 2 of 4
(1,413 Views)

My first thought as well was an I2C MUX.  I found a 1 to 8 MUX from NXP.  So you could use 4x USB-8451 modules, each with a mux, to reach your 32 sensors.  Of course, going with a Raspberry PI or similar might be easier.  A RaspberryPi Pico has 2 I2C ports on it and is dirt cheap.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 4
(1,407 Views)

Thanks a lot for the quick reply! 

 

1) Ah, I get that now - probably smart to have this as a placeholder software-wise.

2) Did I get that correctly - the digital IO lines of the 6535 are not 'tri-stated'? Seems weird that something as fundamental as I2C is not supported by default, as I can configure most GPIO pins on a raspberry Pi as a separate I2C bus. Just curious to understand what digital IO this device is made for then.

 

Unfortunately the 6570 Series seems quite overkill (technically and financially) for the (rather slow) application we have in mind - we wont need the fast sampling rates.

 

I guess in the end, stacking up a couple of Raspberry PIs ( I was able to use 4 I2c busses in parallel) or microcontrollers with 2 I2C busses will be the simpler & more cost-effective solution, as suggested.

Cheers,

Jakob

0 Kudos
Message 4 of 4
(1,383 Views)