Using TM4C1290NCPDT I2C slave modules simultaneously or multiple I2C slave addresses

Hello Ilaam,

The case-1 is very possible where each i2C Slave can have two address using the Dual Address.

The case-2 is not possible, since a Slave when does not see it's own address will NACK the I2C Transaction. There is no method for the I2C Slave on TIVA device to store the address even if the address does not match it's own address. However a SW protocol can be created where the External Master can always write to the I2C Slave using an address and data field indicating that it is going to send an Address change. It is called ARP (SMBus) but is handled by SW.

Regards

Amit

Thank you Amit for your answer.

To make things clear, in the first case I would like not only to use the Dual Adress but also all these i2c modules in the same time : (I2C0SCL,I2C0SDA / I2C1SCL,I2C1SDA / .... /I2C9SCL,I2C9SDA ) which are 10 for the TM4C1290NCPDT according to its datasheet in the signal description section (table page 1254):

The I2C interface signals are alternate functions for some GPIO signals and default to be GPIO
signals at reset.

In that case I would make TM4C1290NCPDT to act like 2 x 10 slaves and it will have 20 i2c slave addresses.

Can you confirm that to me ?

Ilaam

Hello Amit,

Thank you so much ! That's exactly what I want to do : make all slaves listen to the bus and whenever one of them is designated it responds. (the master designates slaves one after another not really in the same time).

I'm glad I finally found a microcontroller having this feature.

Best regards,

Ilaam

Placing so many devices on the I2C bus may reduce I2C signal swings - along w/rise/fall times.  Suggest that the "weak, internal pull-up Rs" not be your choice.  (lower value, external Rs - would seem superior)

Having 20 I2C addresses - concentrated w/in one I2C slave - seems far from, normal/customary.  Even a relatively high performance MCU is unlikely to match the processing capabilities of individual MCUs - each programmed to task - and free running...  The concentrated/single MCU must divide its time between all 20 (assumed) tasks - might not some "bottleneck" be thus caused/expected?

Perhaps you can describe the intent of such I2C, "slave concentration?"

cb1 I see what you mean and I thaught about this problem.

It's true having an MCU to act as 20 MCUs may reduce its performance, but it will do it sequencially. And the MCU won't have much processing to do, it will just access a memory retrieve data and then send it to the bus.

If I use many MCUs instead, I'll have the same problem of the i2c signal swings. The need to have so many slaves is imposed by my client. I have the choice to use different MCUs instead but that caused me a problem of synchronisation as each MCU has its own clock.

But I don't see where can I have a bottleneck problem : each period the master asks a slave. the corresponding slave in the MCU responds : it reads data from its memory (or eventually an SD card) then sends it to the bus. And I thaught that C series MCUs function at 80/120 Mhz which is not bad.

Am I right or am I on the wrong way ?

As all of the data will reside w/in one MCU - the need for 20 I2C addresses seems w/out merit.  (realize this is a client "spec" - but not all clients - at all times - are proper & well thought in their understanding/demands...)  (not to ask - how this - I know...)

Unlikely that anyone has "hitched" 10 identical class peripherals - w/in one MCU - as you intend.  Amit's guidance (I would bet $$$) is theoretical - not based upon practical experience.  You may land in, "uncharted waters."

There are times/places where multiple slaves must properly inhabit the I2C bus.  I see little value in the, "concentration your client apparently seeks" - and the rarity of such application (minus any justification) rings alarm bells...

You may consider blaming me - and asking the client for clarification - as regards such "unusual" I2C device concentration.  Adding the burden of multiple device, address decoding - when all such addresses reside w/in just one device - seems "textbook" in, "what not to do!"

Unfortunately, I won't be able to change the spec. However, the client didn't impose to implement all the slaves in one MCU. He only wants to have different slaves whether they are software or hardware. What matters, is that when the master sends an i2c slave address to the bus, it receives an acknowledgement and the data this slave is supposed to send. There are already systems where the master communicates whith numerous i2c slaves (sensors) and that doesn't cause problems. If concentrating all the process in one MCU seems like "what not to do", I have no other choice than using as many MCUs as slaves (asked by the master) and I'll be facing a new problem of synchronization between them. The synchronisation does nothing to do with the I2C communication, but my slaves have to deal with a data layer and they should have a shared clock or something like that.

Thank you for warning me of the doubted feasability of my idea.

You've provided much more detail here - thanks for that.

Do understand - my goal is not to, "Wreck your deal/party" - simply sound the alert that seas may be high - skies dark...

Read this/other MCU sites re: robustness of multi-slaves on the I2C bus.  We've long used I2C (as well as other serial methods) - developing system robustness in the face of noise or other, "system disorders" is non-trivial. 

Again - our group has had many encounters - but never/ever anything close to that which you/client propose!  Should your system be impacted by noise upon the I2C bus - will your plan include the, "reset of all 20 (or 10) I2C peripherals?  Do you think the MCU designers included such capability w/in their design objectives - and that such was ever exposed to serious test/verify?  (I do not!)

Beware should you stray too far from the herd - risk seems too high - reward not so much - and to whom will you turn to, "duplicate your mass/concentrated - totally unique I2C implementation."  I happen to love Sales as much as you - yet one key to biz success is to know when to say, "No!"  Risk-reward - here - does not meet my group's standards!

Ok, I get you. You're right but maybe I can do some tests to see how many slaves it can handle.

I wonder why is there 10 I2C ports. Maybe implementing 20 I2C slaves would be almost impossible, but when it comes to 5 slaves (let's say) there is hope.

Well, thank you for your help I'll let you know if some tests are made.

Hello Ilaam,

Please note that it is I2C Master and Slave. Having multiple I2C Master helps specially when the Slave devices are such that they can have the same address. Normally, I2C device vendors give the option of selecting the lower 2 or 1 bit Slave address by tie off. However when multiple such slaves have to be put on a board then there could be an issue. One way is to put them on different master bus.

Regards

Amit

Hello Amit,

As I said I can't change the master part. It is already implemented and I have to make the slave part communicate with it.

However when multiple such slaves have to be put on a board then there could be an issue.

Do you mean it is not a good idea to use the different I2C ports to simulate many slaves on the same device?

Hello Ilaam,

I was merely answering the question as to why so many I2C Instances. The Master and Slave both are available for every I2C Instance.

Regards

Amit

Hello Amit,

Ok, having so many I2C instances was basically done for multi master cases.

I'll try the multi slave.

Thank you.

Regards