Hello, I am wanting to add an "Activity" LED to an I2C bus, but only for slave data, not master data. I think normally I would add a FET to the data line of the I2C bus (SDA line), but this will show activity for the master attempting to communicate with a slave device, as well as activity for a slave device communicating back to the master. Is it possible to achieve this by only lighting up the LED from the slave device communicating back to the master?
Thanks and any help or advice is greatly appreciated!

 

If you want an activity LED for slave data, I think you will have to get into the code.

 

Hello, I am wanting to add an "Activity" LED to an I2C bus, but only for slave data, not master data. I think normally I would add a FET to the data line of the I2C bus (SDA line), but this will show activity for the master attempting to communicate with a slave device, as well as activity for a slave device communicating back to the master. Is it possible to achieve this by only lighting up the LED from the slave device communicating back to the master?
Thanks and any help or advice is greatly appreciated!

How do you propose to tell the difference between a transmission from the primary device and a transmission from the secondary device. The SDA line is bi-directional with no indication of where the transmission originated. I suppose you could build a protocol decoding engine into the LED. That might work.

 

Hello, I am wanting to add an "Activity" LED to an I2C bus, but only for slave data, not master data. I think normally I would add a FET to the data line of the I2C bus (SDA line), but this will show activity for the master attempting to communicate with a slave device, as well as activity for a slave device communicating back to the master. Is it possible to achieve this by only lighting up the LED from the slave device communicating back to the master?
Thanks and any help or advice is greatly appreciated!

Your monitor is going to have to sniff the data that is traversing the bus and identify it's origin.

 

I was wondering if there was a way to do something for instance using a diode and only have it light up the LED if it was coming from a certain direction, e.g. if the current on the SDA line is flowing due to the slave driving the line low, versus the master driving it low. I wasn't sure if this was possible or not. I am trying to come up with a hardware only version to drive the LED, versus using firmware and an extra GPIO to drive the LED.

 

You may be able to do what you want using some kind of line drivers at each end, they would send the data back and forth, and you would be able to determine when it was the slave, by tapping the signal at that end.

Keeping synced with the clock could be a problem.

But messing around with I2C signals is asking for trouble, it's not like they're not finicky enough already.

 

I was wondering if there was a way to do something for instance using a diode and only have it light up the LED if it was coming from a certain direction, e.g. if the current on the SDA line is flowing due to the slave driving the line low, versus the master driving it low. I wasn't sure if this was possible or not. I am trying to come up with a hardware only version to drive the LED, versus using firmware and an extra GPIO to drive the LED.

I have worked extensively with I2C devices and systems. I am quite familiar with numerous proposals that "break" the protocol and drive successful operation to a "very low order of probability". This seems to me to be a very dubious proposition. I'm just curious if anybody who has worked extensively with I2C has a similar opinion.

 

I have worked extensively with I2C devices and systems. I am quite familiar with numerous proposals that "break" the protocol and drive successful operation to a "very low order of probability". This seems to me to be a very dubious proposition. I'm just curious if anybody who has worked extensively with I2C has a similar opinion.

Hi Papabravo, I'm not sure I am following what you are trying to say here?

 

You may be able to do what you want using some kind of line drivers at each end, they would send the data back and forth, and you would be able to determine when it was the slave, by tapping the signal at that end.

Keeping synced with the clock could be a problem.

But messing around with I2C signals is asking for trouble, it's not like they're not finicky enough already.

The clock shouldn't play a role here. Plus the clock is only driven by the master. The data line is already pulled high by default with a 10K resistor. So whenever the line is pulled low from a slave is when the LED should light up - e.g. by using an inverter.

How would I isolate that?

 

I don't know.

The only thing I could come up with last night would introduce a voltage drop in the line, and I doubt that would be acceptable.

My idea was to place a pullup at both ends and two anti-parallel diodes in the line and then detect the drop across one of them.

 

If your system can tolerate about a 0.6 volt loss on the low level of the signal (I.E the receiver would have to interpret +0.6 volts as a logic zero.) then the following might work. break the data line and connect the slave end to the emitter of an NPN transistor, Connect the base of this transistor to the master end of the data line. connect a diode between the base and emitter of the transistor with cathode of the diode to the base. So now the data line sees a pair of back to back diode in series with it. (Which gives the 0.6 volt drop in both directions.) Connect the collector of this transistor via a fairly high value resistor (Say 47K) to the base of a PNP transistor whose emitter is connected to the positive supply rail. Connect the LED and it's current limiting resistor between the PNP transistor's collector and the positive rail. The transistors will only conduct when the slave is pulling the data line low. Bear in mind that even when the master is sending data that the slave asserts an ACK condition at the end of each byte of data which would pulse the led on for one clock positive condition.
You could reduce the voltage drop if you could find a germanium NPN transistor and germanium diode.

Les.

 

Hi Papabravo, I'm not sure I am following what you are trying to say here?

I'm trying to say as simply as possible that an I2C system should be constructed EXACTLY as described in the specification without hanging any extra cruft on either SDA or SCL. We had one "genius" hardware engineer who thought it would be a good idea to run the I2C bus through an FPGA to avoid having to do future board turns. He never could get the I2C to work properly and reliably. I got my way and we ran the I2C directly from the primary device to each of the secondary devices by the direct route with the proper pullups and lo and behold things started to work like they were supposed to work. Who'da thunk it? For me the lesson was simple - don't screw with the I2C for any conceivable reason. Your mileage may vary. Was that explicit enough for you? @Mahonroy

 

Why not just detect the state of the R/ not W bit is the slave address byte and use it to set a latch. Then detect a stop condition to clear the latch.

Les.

 

Can you do that with external hardware?

 

Can you do that with external hardware?

Yes you could conceivably do this with an FPGA. I don't recommend trying to do it with MSI parts. IMHO it is a really really bad idea. See Post #12.

 

Re Post #14 I don't see ant reason why it should not be possible. A digital storage scope must be able to do it as it can display the transmit and receive data as separate traces. It can even display the data in both directions. I found this function very useful while writing code to run on a PIC12F1840 to read the data from a BMP280 (Bosch temperature and pressure sensor.) If I was doing this my first approach would be to use a microcontroller. ) Probably one of the PIC range.)

Les.

 

Why not just detect the state of the R/ not W bit is the slave address byte and use it to set a latch. Then detect a stop condition to clear the latch.

Les.

That would be a neat, if complex solution. A small MCU monitoring the bus would do it.

Your earlier post using a small resistor in-line can be made to work, my experience of I2C is that it is quite robust as long as you don't push too hard. I've used the same technique on CANbus to ID which device a transmission was coming from (several identical commercial units with no access internally).

Here's an approach based on my CANBus solution...