??? 03/01/04 12:59 Read: times |
#65726 - RE: i2c 100khz & 400khz Responding to: ???'s previous message |
From what I read in the data sheet it appears to me that you would be able to change the Cr2->CR0 bits when ever you wanted to. I do however see a problem for you if you want to mix the two speeds of device types on the same SDA and SCL lines. Since all slave devices on the bus get address at the same time they must all be capable of operation at the same speed. If you were to attempt to program the controller chip at 330 kHz to address your faster devices then you would be technically be violating the timing spec of the slower devices which must also listen at the same time.
I can see a few options around this problem. 1) You could simply operate all devices at 88 kHz. 2) You could try to replace your slower devices with other newer part numbers that are capable of faster speed operation. 3) You may elect to use two of the PCA9564's and have two I2C busses on your board, one at 88 kHz and one at 330 kHz. 4) You could build some type of interface circuit that permitted you to switch the SCL/SDA connections of the PCA9564 to two separate I2C busses. This circuit would have to support bi-directional buffering which gets pretty messy when it needs to include switch off capability. 5) You could try a scheme with a single I2C bus and a single PCA9564. This would be tricky and experimental but would may work just fine. The concept would be that whenever you were ready to start an I2C transaction you program Cr2->Cr0 to 100b for the slow speed (taking the data sheet warning into considerstion). Then program to have the '9564 send the start sequence followed by the address sequence. Your software would monitor until the ACK was received from the addressed device. Then you would determine the operating speed of the target slave device. If it is a 100 kHz device you would continue operation through the rest of the transaction sequence at the 88 kHz rate. For a higher speed device you would re-program the Cr2->Cr0 bits to 000b. Then the next and succeeding bus transfers up to and including the stop transition would operate at the 330 kHz rate. This concept does make an assumption that the slower devices would ignore the higher speed clocking on the bus since they were not addressed when you are trying to communicate with the higher speed target. This could be chancey because it is possible that a low speed device could mis-interpret high speed clocking and think that a new start/addressing sequence is going on. Personally, I would go for Option 1 if a mix of devices was involved. The I2C bus has never been a barn stormer for getting large amounts of data moved around at high speed. It may be possible for you to consider something else as well. Evaluate where you really need the speed of 400 kHz slave devices and consider alternate type devices instead. In my designs I use I2C bus devices when low band width is involved. But if say an EEPROM is needed where it gets read and/or written a lot and higher bandwidth is needed then I elect to use SPI type interfaces to these devices because of the faster clocking that can be had and the lower overhead in transaction prototcol. Of course that higher performance costs a little bit in the hardware area. Michael Karas |
Topic | Author | Date |
i2c 100khz & 400khz | 01/01/70 00:00 | |
RE: i2c 100khz & 400khz | 01/01/70 00:00 | |
RE: i2c 100khz & 400khz | 01/01/70 00:00 | |
RE: i2c 100khz & 400khz | 01/01/70 00:00 | |
RE: i2c 100khz & 400khz | 01/01/70 00:00 | |
RE: i2c 100khz & 400khz | 01/01/70 00:00 | |
RE: i2c 100khz & 400khz![]() | 01/01/70 00:00 |