Not necessarily! If they are open collector devices, they will draw very little current when they are off. Only one device should be active at any one time.
Keith

All the receivers are in parallel and lower the impedance that the driver of the bus must overcome. SDA is a party line. SCL has the same situation to contend with.

 

There is a graph somewhere.. I'll try and dig it out... It proposes 0.6 ~1.8k no lower or the level stays high, but several devices do have an effect on the clock pin, as Papa just explained..

 

The scanning program was possibly never intended to be used with more than one device connected at a time.

The scanner works ok with multiple ICs. It is a very handy tool!
Try running the scanner and adding devices one at a time to see if there is one particular device that is causing the problem.

Not necessarily! If they are open collector devices, they will draw very little current when they are off. Only one device should be active at any one time.
Keith

I agree. A problem may occur if each device was on a pre built board and included pullup resistors. If so, adding each one will be putting extra pullups in circuit. But that may not be the case.

 

RE:""What is the total length of the bus?""
Oh huge thanks to Papabravo for this sentence alone. I just just not made a huge whole-crushing mistake designing the ion beam power supplies bundle as PC driven system by i2c. So, thanks to this sentence I searched an find the following:
""With current source pullups (!!) you can go to 400pF, but not with resistors. If your wire is 20pF/30cm and you have another 50pF of stray and input capacitance, you're limited to 2.25m of cable length. Different assumptions will lead to different numbers""

My target was 2 meters, each power supply have own 328 processor and i2c for easy paralelling oversen by other 328 having single USB to comp with Labview runtime. Somehow I must sticking nearer to usb seems. The count of steerable supplies must be about two dozens, therefore straight connect to usb is not rational and Kamak or HP interface is sure overkilling."". Indeed, to have a kontusion from heavy hit to the own competence ceiling may be painful. You saved me from such.

Here is bit more in-deep from other source:
"The insane sounding lengths like 10, 25, 100m are perfectly possible, and I use the method often (with UART not I2C, but the method stands) when I need to put stuff together quickly. It's not exactly the best way, though.
The key is to know your input voltage threshold. Make sure the voltage drop in the ground lead is well below this, or else a transmitter at a high ground potential will not be able to pull the voltage low enough. Lack of tolerance for ground offsets IMHO is the biggest reason to use RS485 or can transceivers (I2C over CAN is mentioned in a few application notes).
Ideally, all devices will have their own wall wart and battery and no power will be sent over the ground wire between devices.
But, lets take CAT5 for example. CAT5 can't be higher than 52pf/m, or it isn't CAT5. 100m of 52pf cable has a capacitance of 5200pf or 5.2nf.
5.2n times 20kohms (pullup) gives a time constant of about 10^4 microseconds. That limits speed to about 10kHz or so.
Using 2.2kohm pullups, you could probably get to 100kHz. I have heard that devices should have a resistor on SDL and SCK, because of the big capacitive load they are driving, of something like 180 or 200 ohms.
But honestly, I2C is not at all the way to go for long distances. CAN transceivers or RS485 used with normal UART is a robust solution with very good fault protection, ESD resistance, speed, distance, etc, at a cost of a dollar a chip or so, ground offsets don't matter nearly as much so you are free to carry power along with data.
The only downside is that a can transceiver can reach 70ma transmitting and 1 or 2ma just listening, so I2C or direct TTL UART might be useful in extreme low power situations, but consider how much time you actually spend sending." [electronics.stackexchange.com/questions/106265]

 

I got loss on all the answers......

I have to tyr to run a scan to each device for 2 hours
when connect the INA219 , RTC1307 - the scanner get stuck after 30 min
when I connect the Oled - it's run until this morning (more then 10 hours)

now what?
what could be the problem in this simple i2c ?

what else I can check I do ?

Thanks ,

 

All I can think of is to check your power supply. Stopping after a time may be the PS is quitting after a while.
Are you running on a supply or USB?
And maybe try with different boards???

 

I'm connectin using usb (arduino-computer )
I don't think this is the probelm - because it just 1 devcie connected

first time in a very long time I'm going to give up about something

 

Could you include a wiring diagram of how everything is connected?

 

Try again, but with the Arduino running on external 9V, not the USB. Full 5V may not be available on some USB connections I have found.
And have you used another Arduino and/or set of boards? There may be a faulty on in the batch.

 

I have experienced similar Arduino hangup problems when I used a marginal power supply. I solved them by using a much more reliable supply than an unregulated wall wart.
Keith

 

I wonder if you have things stuck in a loop in your code.

 

I wonder if you have things stuck in a loop in your code.

The I2C scan program is a loop. It poles each possible address in turn and then starts over again.
Keith

 

it's not a code issue ,

I think I have found the problem
I replace the INA219 with a brand new one that I bought from another store ...
reboot the arduino
and let the code run for a night - evetyhing is working without any problems
the starnge thing is that I replace the ina219 before (but it was from the same store..... this is why I thought something is wrong in my connectios or something.....)
F@$K this store

I have also connect it to 3.3V - and I'm wating to see that it's still OK

now I have another question :

if everything will work without any problems on the Arduino and I will see all devcies for a long time
can I take the same circuit and just connect it to Raspberry PI ?
without adding anything else?

I know the pi GPIO is 3.3V only (this is why I'm testing now on the adruino using power 3.3V)

Thanks ,