I2C port scanner

[Aswin]

Hi,

I want to make a port scanner for I2C devices. This scanner needs to detect all I2C addresses in use on any of the NXT sensor ports. I do not want this scanner to read from a register address as not all I2C devices use registers and even if they do one cannot be sure about the registers in use. I do not know yet how to build this scanner, so I'm asking for advice here.

I am aware of the sample program I2CDevices. But this sample reads one of the registers to detect a sensor. Also, this program stops scanning a port after having found the first device on a port.

[gloomyandy]

Hi Aswin,
There is no way to do what you are trying to do. There is no standard for how i2c devices should respond, some may be write only devices and so will not respond to read requests, some may only respond to specific commands, some may only respond to a read on a particular register address. Having said that for Leo type devices a suspect that scanning all possible i2c addresses using a read request at the standard Lego type/id range, followed by a read with no register address specified will pick up most devices and will be pretty safe. Scanning using a write request could potentially be hazardous due to the device using the write as some sort of command.

You will probably have to make use of the i2cTransaction method to perform the scan to allow address and register values to be easily changed. I've done something similar to this a number of time using a quick mod of the i2cDevices sample when wanting to identify the address currently assigned to devices that allow the address to be changed...

Out of interest, why do you want to do this? It is unlikely that you will be able to identify none Lego devices without having a pretty good idea of what device it is you are looking for...

Andy

[Aswin]

Out of interest, why do you want to do this? It is unlikely that you will be able to identify none Lego devices without having a pretty good idea of what device it is you are looking for...

Andy

I'm testing a device that supports multiple addresses at the same time. One of these addresses should be unique to a single device on a port, this address can be used to read or write to the device. The other addresses are meant to be shared among multiple devices on a port. This allows one to send an instruction to all of them in one go. The addresses that are shared do not support reading operations to prevent answers from multiple slaves. Both types of addresses, unique and shared, are user configurable (software or hardware).

I want to find out all of the addresses that are in use, including the shared ones, to be able to test if I successfully configured the device. I do not have the intention of being able to identify the device.

[skoehler]

So if you're talking about a particular device, you can simply issue a few reads and see to which reads the devices responds. You can use I2CPort.i2cTransaction for that.

[Aswin]

you can simply issue a few reads and see to which reads the devices responds

Well this is part of the problem. The device does not always respond to I2C reads. If a general call address is used the device should not respond to a read, just to a write.

I have a bus pirate to investigate I2C communication. I can use this to scan for addresses. So it is not really a problem if this cannot be done on the NXT. It is only annoying to swap between NXT and bus pirate all the time.

[gloomyandy]

So what does the bus pirate do to locate the device? I don't see any reason why you can't do the same with the NXT...

Andy

[skoehler]

You cannot do zero-length reads. Just zero-length writes. (if the read length is zero, leJOS performs a write transaction, I think)
However, can the I2C master tell, whether the slave responds to a zero length write? Then Aswin can scan the bus doing reads and writes.

[gloomyandy]

The current code does not allow zero length writes f readlen + writelen <= 0 it generates an error. I'm not sure if a zero length write is even possible/allowed in i2c. Similarly I'm not sure if a zero length read is allowed. In both cases I'm pretty sure that the slave will expect to read or write at least 8 bits. The best I think you can do would be to issue a write (which would generate an ack on the address), and then abort the write by sending a bus reset/end. At the moment we don't have code to do this but could probably add it. However I'd like to understand what the bus pirate does to identify a device, as I suspect this is a good way to do it...

Andy

[Aswin]

Hi,

Here is how the bus pirate does it.

Scanner details
Details about the address scanner macro are at the end of this post and around here in the source.

For I2C write addresses: the BP sends a start, the write address, looks for an ACK, then sends a stop.
For I2C read addresses: the BP sends a start, the read address, looks for an ACK. If there is an ACK, it reads a byte and NACKs it. Finally it sends a stop.
When the I2C chip responds to the read address, it outputs data and will miss a stop condition sent immediately after the read address (bus contention). If the I2C chip misses the stop condition, the address scanner will see ghost addresses until the read ends randomly. By reading a byte after any read address that ACKs, we have a chance to NACK the read and properly end the I2C transaction.

Hereis the link to the page I quoted from.

[gloomyandy]

Hi Aswin,
Does your device respond to both the read and the write scans used by the bus pirate? I suspect that the write scan would be the easiest for me to add to leJOS as we can simply use a zero length read+write to trigger it. The read scan is basically exactly the same as performing a single byte read (using leJOS), but I guess your device may not respond to that...

Andy

[skoehler]

@Aswin: why can't you simply issue a serious of read/writes that are valid for your device?

[Aswin]

Hi,

Thanks for the help thus far. There was one thing I overlooked during my tests . The bus pirate reported that address 0x00 was in use for read and write. My NXT scanner (based on (I2CDevices) didn't. This was a software glitch as the program scanned from port 0x02 on. Therefore it missed the port 0x00. I shamefully corrected this and the NXT scanner now finds all addresses in use for read. It still doesn't find the addresses that are solely for writing but I will try using a valid command for the device as Skoeler suggests.

[gloomyandy]

Interesting address 0 (I assume this is the device address) is a reserved address and is used as a "General call address" in this case the read/write bit has a special meaning and the next two bytes are used as command bytes... See section 3.2.10 of the following...
http://www.nxp.com/documents/user_manual/UM10204.pdf

Andy

[Aswin]

Yes, I knew that. But I didn't know I configured my device to use this address. That is exactly why I needed a port scanner.