Background:
I have 2 sensors that has a single static I2C address (Multiple addresses have not yet and may not ever be added to the device according to the manufacturer). To read the 2 sensors I used a multiplexer which worked great but the extra multiplexer call and then just calling 2 devices instead of 1 devices slowed reads down (of course) too far for what we need. So what I am hoping to do is have 3 Arduino devices, 1 'master' which will take the original commands and use the sensor data as needed. Then 2 'slave' devices each running I2c with the 1 sensor on it's bus that takes a command from the 'master' (IE start taking readings/stop taking readings) and return the data to the main device as it comes in.
Question
Which protocol (besides I2C since I can't have 2 addresses on the bus, and the multiplexer with 2 devices calling it will only cause issues and potential misfires with both sensors running simultaneously) is best suited for the Arduino communication I am trying to accomplish? Or is there a different device I can use to 'spoof' the I2C address of the sensor in question? And if that is true can a 'slave' request data from another 'slave' via I2C?
Two slaves with a master is good. It will work. You can use serial (UART) communication.
The master could be the Arduino Mega 2560, because it has 4 hardware serial ports.
A combination on the I2C will become a big unknown pile of problems.
I'm not yet convinced that a mux is too slow.
You could increase the I2C speed to 400kHz, and use a simple mux with switches. If I remember it well, only the SDA (or was it the SCL) needs to be mux'd when a simple mux is used.
You could use the ATmega direct pin command to switch the mux in less than 1us.
Can you tell which sensor it is ? or is that a big secret ?
I'll do some research into Serial UART, don't have a MEGA here so I'll have to get my hands on that too
No, no secret, it is the LIDAR-Lite from PulsedLite3D (LED not Laser version). It's not released yet, but we have been testing with it for a project with an evaluation unit. Thing is super fast, 70+ reads per second, but when using 2 + mux plus bloat I guess I'm down to about 30 a second, which isn't fast enough to collect the data we need. 70 should do it (and they say I should be able to get closer to 100/sec so that would be even better). So in my head now (after your input) I'm thinking a mega and 2 micros just for the I2c for the sensors might do the trick.
You can use two I2C buffer chips with enable inputs (say the PCA9517) as a "MUX", that way the switching overhead is a simple write to a digital output.
The 400kHz and switching within 1us (with a simple switch-mux) is also for a normal Arduino board, like the Arduino Uno.
I only mentioned the Arduino Mega 2560 board, because it has 4 hardware serial ports, which you need when you receive lots of data from multiple other Arduino boards. That is only needed when you decide to use an Arduino board per sensor.
Two Arduino Micro boards with an Arduino Mega 2560 as central unit is a good choice. The Arduino Micro has also a spare hardware serial port which is not used (pin 0 and 1, "Serial1"). The Mega board uses the first serial port to upload a sketch, the other three are free.
However, I think with only 100 samples per second per sensor, even the Arduino Uno (with 400kHz and simple mux) should have no problem at all.
Some examples for I2C devices have 90% overhead in the code (I'm not kidding!). Perhaps your code can be optimized ?
Or the sensor slows the I2C down, in that case you have no other option to use an Arduino board per sensor.
I just noticed the 20ms "aquisition time", the 100Kbit speed, the I2C command "Single Distance Measurement". That smells like timing trouble for you. Can you sent a 'start' and check 20ms later to see if it is ready ?
