Synchronizing two i2c devices on separate i2c busses STM32

[Martiska.Greg]

Posted on April 27, 2011 at 15:46

Synchronizing two i2c devices on separate i2c busses STM32

[Martiska.Greg]

Posted on May 17, 2011 at 14:33

Thanks for the reply. Is it possible to write to two IO ports or I2C ports simulataneously? Even a few milliseconds difference between writes would be unacceptable for the application as I am syncing 100kHz signals.

I was thinking of connecting both devices to the same I2C bus and writing to both devices simultaneously. Then when I need to read or write to either device I could disconnect the appropriate SDA line with an external switch. The only problem is that it appears that the devices send an acknowledge byte on a write command. It may be possible to turn this feature off though.

[John F.]

Posted on May 17, 2011 at 14:33

Some STM32 devices have two I2C engines. You could use both and write software that drives both simultaneously. They might be a few microseconds different. Otherwise do the I2C in software and drive port pins directly writing to the pins simultaneously. GPIO_Write( ) writes data to the specified GPIO data port.

[Tesla DeLorean]

Posted on May 17, 2011 at 14:33

forum dupe

[John F.]

Posted on May 17, 2011 at 14:33

Bit banging with both devices on one port (so you can drive both simultaneously) is your best bet. However, it sounds like I2C devices are not a good choice in this application. You mentioned something about ''syncing 100kHz signals''. Why not look at other hardware options?

[Tesla DeLorean]

Posted on May 17, 2011 at 14:33

The only ways you're going to keep these SOBs in lock step is to a) software bit bang GPIO's simultaneously in the same IO bank to emulate I2C, b) implement it in a CPLD, or c) use a common master clock source to drive the buses.

Ideally you could use a synchronous SCL source, perhaps you could kludge this up with two STM32 I2C peripherals in SLAVE mode, and drive the SCL from a looped back GPIO. The controllers might permit this to work, and give you sufficient control of the protocol. But I'd class that as a huge hack, and haven't tried it.

The bit-banging suggestion would be effective and simple/quick to implement.

[Martiska.Greg]

Posted on May 17, 2011 at 14:33

Thank you for your responses. The device I am trying to use is an SoC that was designed for a specific purpose. I am trying to extend its operation by using two of the devices in sync. However, the manufacturer did not envision using the devices in this way so there are no sync pins and only fixed addresses. They can share a common clock thought. After reading your responses and speaking with the manufacturer, I have decided to switch the input of one device and run two cycles instead of using the two device model. This  takes more time for the measurement but elliminates the sync problem and some calibration issues between the two devices.

However, I am curious about the bit banging idea. I understand what bit banging is but I have never implememted it.How would I connect the devices? When you say use one port does that mean using one io pin and one clock pin or can I write to two pins and clocks simultaneously?

Thanks again for your helpful answers.

For Clive1 - I have ready many of your comments on this site and have learned a great deal. Thanks for being such a great resource.

[Tesla DeLorean]

Posted on May 17, 2011 at 14:33

However, it sounds like I2C devices are not a good choice in this application. You mentioned something about ''syncing 100kHz signals''. Why not look at other hardware options?

I2C was a pretty cheap-n-nasty in the 1990's, and I worked for Philips, the world has moved on a lot since then.

My guess is that is a frequency source, PLL, or tuner of some sort.

The part hasn't been mentioned, but the lack of individual addressing, and the lack of a common sync pin between them certainly does scream for a review of if the part is even truly appropriate for the application. It must have a feature required, but the exact specification/application hasn't been spelled out.

[Martiska.Greg]

Posted on May 17, 2011 at 14:33

I think I've got it on the bit-banging. It actually looks straightforward. I think I am going to prodcue a prototype with the option for one or two devices and see how it goes. My only question is how to switch the SDA pin from output to input. Do have have to reinitialize it or is there an easier method or function? 

[Tesla DeLorean]

Posted on May 17, 2011 at 14:33

Bit banging is generally used to describe a technique for emulating hardware protocols by driving GPIOs with appropriate levels at appropriate times. Sometimes timing is critical, like say for a serial UART type signal, and you'd need to use tight software timing loops to achieve appropriate bit timings. I2C is somewhat easier, as the clock doesn't have to be accurate or constant, the user gets to drive the bus as what ever speed is convenient, obviously within the 400 KHz, or whatever limit the peripheral has. Sync is often accomplished by holding off on the very last clock, ie for an RTC for example, wanting for the top-of-second before loading the timing registers internally by the RTC.

By a common GPIO bank, I mean say using PA.03, PA.05 and PA.07 (numbers plucked out of the air, no specific STM32 utilization considered). These all live on bank A, and you can modify them with a single write to a GPIO register. The pins will all transition at the external interface on the synchronous clock of the GPIO peripheral.

You'd define them as OD type GPIOs, perhaps 2MHz in terms of edges/drive/slew, and SDA1, SDA2, SCL respectively. You could use two SCL's but I wouldn't bother. Then you'd transition the pins in protocol sensitive manner (hold times, relative/temporal placement, etc), checking on ACKs, returned data, etc. If it just involves writing to the I2C slave, that would make things a tad simpler.

[Martiska.Greg]

Posted on May 17, 2011 at 14:33

That is a great suggestion. I am not sure if I will have enough pins thought. I was thinking that there would be an easy way to toggle the IO pins between input and output but maybe not.