I2C Slave?

The I2C hardware on the AM3358/59 SoC  on the BeagleBone Black is perfectly capable of operating in slave mode. The real question is do any of the Linux I2C drivers support it ?

If they do all you need to do is figure out how to open the I2C interface in slave mode. If they do not the only recourse is to either write your own I2C driver or find someone that will

do it for you.

I would be surprised if there were no support for a slave mode in the drivers. While it is fairly unusual for I2C to be used this way on a SBC, it is not unheard of. There is another

forum member, shabaz, that has done a lot of experimenting with the BeagleBone Black so you might try to contact him to see if he knows anything about this.

I must admit I've never used a microcontroller/processor in slave mode, this is quite unusual. Multi-master mode is supported, but this is something I'm not familiar with either.

The details are in the AM3359 tech docs of course, but as you say I don't know if the standard I2C drivers support it. It may need some custom driver. An easier option would be to use

a different interface, i.e. change the AVR code.

Or you could bit-bang (easier than writing a driver but will still take you some effort if you're new to it. If you want to try this, search for PRU examples).

I once wrote a single-wire interface which allowed chaining of multiple devices in/out (much like the WS2811 or 'neopixel' style LEDs do) for PIC devices, but I don't have the code for that

any more.

So sorry Greg, but this is unusual enough that I don't have an answer. What exactly are you trying to do? (End use-case). Are these 25 devices over some distance?

Thanks for the responses, Gary and shabaz! I had already done some surface level searches for Linux I2C drivers that also do slave-mode but didn't come up with anything conclusive. And I had almost forgot about the PRU since purchasing the BBB, but my project isn't necessarily time-sensitive enough to justify the extra effort. Both are good to keep in mind for later optimizations.

My project: I'm trying to have the BBB act as the main intelligence to a connected grid of 2-3 inch "blocks" controlled by AVRs. The blocks could be ordered in different ways, say, 5x5 or 3x8 or even mixed-length rows, but the likely max distance should be less than 3 feet or so which shouldn't be too long (I hope). The idea was I could hard-code an I2C address for the BBB into each AVR block. Once connected, the microcontroller could then take control (become master) of the shared I2C bus and address the BBB (as slave) to pass along its own I2C address, effectively allowing the BBB to collect the addresses of all the blocks present. Once the BBB (now as master) has all the block addresses, it can address each AVR (now switched to slave) individually over the shared I2C to send commands, read other values, etc.

Not all blocks are required and they will be disconnected and reconnected while the full system is running. Also, order matters - so I wanted each AVR address to dynamically reflect its "location" so I didn't want to just assign unique IDs to each AVR manually. (I've worked out dynamic location separately from the I2C stuff). Nor did I want to try to keep track of the IDs of 25+ nearly-identical blocks. I really liked the idea of each block "introducing" itself once connected and I thought the 2-way multi-master I2C common bus was a good and easy solution.

What I might do for now, at least to get a first working prototype started, is fairly regularly poll all 127 or so possible I2C addresses from the BBB and see who responds. This means the protocol is the more traditional 1-master, several-slaves I2C and should at least get me started. It's not as cleanly interrupt-driven like the "introductions" would have been, but it'll get me to the next development stage quicker.

Thanks again for the responses! I really appreciate the feedback.

Now it is clear! The switching of master slave in the relationship is not necessary if you let the master "broadcast" a welcome message to see who responds with an address. The broadcast would happen at say 5 second intervals. Reserve address 127 as special for only this purpose. Then a slave needs two address to know: itself and the special 127 address. This is how routing occurs.

"if you let the master "broadcast" a welcome message to see who responds with an address"

The address used for this in the I2C specification is the general call address. I think your are correct that this is what Greg is looking for and will simplify

what he is trying to do.

Greg, if you haven't already I suggest you Google UM10204 which is the document number for the NXP Semiconductors pdf of the official I2C specification.

The current version is revision 6, earlier versions are also available. NXP Semiconductor used to to be Phillips and they were the originators of the I2C bus.

"if you let the master "broadcast" a welcome message to see who responds with an address"

The address used for this in the I2C specification is the general call address. I think your are correct that this is what Greg is looking for and will simplify

what he is trying to do.

Greg, if you haven't already I suggest you Google UM10204 which is the document number for the NXP Semiconductors pdf of the official I2C specification.

The current version is revision 6, earlier versions are also available. NXP Semiconductor used to to be Phillips and they were the originators of the I2C bus.

UM10204 I2C -bus specification and user manual