I2C timing.

steprog · 2009-09-22 08:57

Hello,
Can anyone tell me what the speed is set for with the I2C objects here? Im trying to interface with a cypress psoc that is spitting out three integer values. Anyway, I have it set for 100k and I can't find a reference for the I2C object.

Javalin · 2009-09-22 12:28

they run as fast as they can - no specific timing is set. Is your PSOC master or a slave?

James

Mike Green · 2009-09-22 14:04

The speeds are set by the I2C bus master. This is a clocked protocol and there are really 2 standards for timing, one with a clock up to 100KHz (low speed) and the other with a clock up to 400KHz (high speed). Many parts now allow clocks up to 1MHz.

Objects written in Spin will run maybe at 20KHz. Objects written in assembler can run typically at 300-400KHz, perhaps as high as 1MHz. The I2C driver used in FemtoBasic has a user selectable speed, either 100KHz or just under 400KHz.

steprog · 2009-09-22 18:16

Hi Mike,
I was using your basic i2c driver and didn't find any speed controls associated with that. Should I try to find an object that uses FemtoBasic?
Thanks, Greg

photomankc · 2009-09-22 18:24

Unless you need a certain speed for your application then there is no reason to be concerned with it. The slave device is clocked by the master, so it runs at whatever speed the master flips the clock at. It doesn't matter if its 10KHz or 100KHz or 400KHz as long as you aren't driving it faster than it can physically respond. So what Mike is saying is that if you use basic_I2C_driver then you will get ~20KHz bus operation. So if your code doesn't need the data any faster than that then you should be fine. If you need a faster driver to get the data quicker then the femtobasic package has one that operates at 100 or 400KHz but it's not nearly as simple to use.

---Edit---
So is the Cypress device running as a slave? If so I don't see why it would have a setting for clock speed. It shouldn't be spitting out anything until the master clocks out each bit.

Post Edited (photomankc) : 9/22/2009 6:34:02 PM GMT

steprog · 2009-09-22 18:33

Im using a psoc device as a capacitive sensor. Having trouble getting the i2c demo to even see the psoc during the scan. I got both legs pulled up and I tested the psoc using an USB to I2C bridge.
A little stump.

steprog · 2009-09-22 18:35

The psoc is a slave

photomankc · 2009-09-22 18:40

I have some code I used a few days ago playing with I2C to scan the bus and report any devices it found. I'll see if I can post that up tonight. I used the same bus as my boot EEPROM was on (both pullups present on my board) and it was able to find both the boot EEPROM the aux EEPROM and the PropSlave I had on the bus at the time which helped to let me know that at least the bus was working.

Javalin · 2009-09-22 18:47

>I2C to scan the bus and report any devices it found
the i2cObject v2 already does this

James

steprog · 2009-09-22 18:49

using the I2C demo I was able to find the boot demo but no luck with my device. Please post it I would like to see another example. Old Newbies can use all the help they can get.

Timmoore · 2009-09-22 18:55

There are 2 things I have run across that can cause problems with I2C on the prop
1. If the I2C slave requires clock stretching. Most implementations of I2C for the prop dont support clock stretching. Many I2C slaves based on micros use clock stretching, sometimes you can get away without it if you ignore the bad values that occur when the micro isn't ready.
2. If the I2C slave is also a SMBUS slave then there is a minimum clock speed that SMBUS requires and the I2C spin implementations I have tried on the prop break that timing. For example the I2CObjectV2 i2c scan will cause problems for SMBUS slaves - they tend to reset during scan and no longer communicate on the bus, the MLX90614 is an example of an SMBUS slave that resets with I2CObjectV2.

steprog · 2009-09-22 19:01

Would the clock stretching thing show up when you are doing an initial scan?

Timmoore · 2009-09-22 19:16

I believe it could, though I dont remember a case where I have seen it.
My understanding of the I2C spec is that a slave can delay the master by holding the SCL low at anytime the SCL is low, i.e. when the master stops holding SCL low, it should wait until SCL is high before continuing.
My version of I2CScan that meets the SMBUS timing doesn't do clock stretching and so far I haven't seen a problem.

Do you have pull ups on both SCL and SDA - some of the prop boards dont have pull ups on both

steprog · 2009-09-22 19:32

yes pullups on both. I need to go back and see the values again. I got 2 pull ups on the SDA line and it may be too low parallel resistance.

photomankc · 2009-09-22 19:38

My scan code is basically TimMoore's code just hacked up to work with my 4x20 LCD. I understand the basics of the bus but I get lost quickly in the actual bit-fiddeling that goes into getting the data out onto the bus. I want to work on my own assembly version someday but that's a long way off right now.

Agent420 · 2009-09-22 19:42

>I got 2 pull ups on the SDA line and it may be too low parallel resistance.

I'm not an I2C guru, but don't you typically only require 1 pullup / termination?·

I typically use 4.7K for 5v data lines on other projects, though I thought I had read that lower values such as 1.8k provide better performance at higher rates.

Too low of a resistance might damage the i/o pins, no?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

photomankc · 2009-09-22 19:45

Timmoore said...
There are 2 things I have run across that can cause problems with I2C on the prop
1. If the I2C slave requires clock stretching. Most implementations of I2C for the prop dont support clock stretching. Many I2C slaves based on micros use clock stretching, sometimes you can get away without it if you ignore the bad values that occur when the micro isn't ready.

It it expensive to check for it? I was wondering since the stuff I'm considering is very similar to what you do with your sensor board. A device that is controlling various hardware and then connecting to I2C to allow another controller to command it. So I was looking around for stuff that allows for Clk Stretching to keep it as flexible as possible to interface with various other controllers.

steprog · 2009-09-22 20:09

I don't know where but I did see it someplace in one of the objects. Perhaps the i2cobjectv2. I'll have to check again. At the time I didn't know what time stretching was.

Timmoore · 2009-09-22 21:38

I have attached my version of i2cobject v2 that supports clock stretching. For clock stretching you must have pullups on both sda and scl so this version only supports pullups. You will see 2 versions of the main read/write routines -e.g. read and readns. Read is with clock stretching, readns is read with no clock stretching. I have also attached by version of i2cscan, it basically inlines all the i2c code so its fast enough for smbus but its still in spin.

steprog · 2009-09-22 21:47

Thanks Timmoore,
Ill check it out and see if that fixes my issues.

Timmoore · 2009-09-22 22:41

I was just reading this Psoc app note http://www.cypress.com/?rID=34486
It says

"The I2C specification indicates that this is an optional feature; not all I2C devices need to support clock stretching. However, at this time all Cypress I2C slave user modules stretch the clock. If a master is used that does not support clock stretching, the bus can lock up and fail to reset"

steprog · 2009-09-22 23:33

Thanks Timmoore,
Your more diligent here than myself. I will let you know how it goes.
Greg

photomankc · 2009-09-23 01:03

I see Tim posted his i2cscan and object so I'll forego posting mine.· It was simply a customized version of his.

·

steprog · 2009-09-23 01:27

Thanks Guys
You fellas are great. I feel like I got guardian angels or something out there.

Peter Jakacki · 2009-09-23 03:29

Special features of the I2C spec such as clock stretching and bus arbitration are really only necessary for multi-master implementations or bit-banged processors acting as slave I2C devices. These specs are mainly from the very early days of I2C decades ago but practically all implementations are single-master with dedicated slave chips or micros with dedicated I2C hardware. You can implement the full spec but I'd be very very surprised if you ever have a need for it, I certainly never have. Anyway anything that required clock stretching would be an antique most probably and you certainly would want to avoid designing a slave that required it as this can lock-up the bus and timeouts are required etc.

*Peter*

Timmoore · 2009-09-23 03:35

Peter, I have many slaves that use clock stretching, some I can get away without by ignoring bad values and filtering but they work better with. examples are hmc6843, i2c-it ir ranger, srf10, etc. many of these are based on small micros without hardware i2c and are bit-banging the i2c slave.

Peter Jakacki · 2009-09-23 03:54

Ah, I am surprised that I2C devices have been implemented this way. I know that even some of the very early micros with I2C hardware only supported bit-by-bit mode so they automatically held the clock low until an ISR got back to servicing them. I couldn't find any info on the first device you mentioned but found this in the FAQ of the SRF10:

Q. My software master I2C code does not read correct data from the SRF08/SRF10, but its works fine with an I2C EEPROM chip. Why is this?
A. The most likely cause is the master code not waiting for the I2C bus hold. This is where the slave can hold the SCL line low until it is ready. When the master releases SCL (remember it's a passive pull-up, not driven high) the slave may still be holding it low. The master code should then wait until it actually does go high before proceeding.

It is not necessary for any design to stretch the clock except for what I would term a kludge to get around a poor implementation. I can use sub $2 micros that support I2C properly but fair enough that you allow for them I guess. I am not aware of any dedicated I2C chip stretching the clock though.

*Peter*

steprog · 2009-09-23 09:19

Timmoore said...
I have attached my version of i2cobject v2 that supports clock stretching. For clock stretching you must have pullups on both sda and scl so this version only supports pullups. You will see 2 versions of the main read/write routines -e.g. read and readns. Read is with clock stretching, readns is read with no clock stretching. I have also attached by version of i2cscan, it basically inlines all the i2c code so its fast enough for smbus but its still in spin.

Hello Timmoore,
I tried running you i2cscan unfortunately I couldn't find the fullduplexserial4c object you refer to. I checked the exchange and didn't find it. Could you refer that to me?
Thanks,
Greg

Timmoore · 2009-09-23 16:21

Heres an archive of a i2cscan tool. I cut and pasted from one of my apps, it compiles but I havn't tested it.

agodwin · 2009-09-23 18:57

The MAX1139 ADC uses clock stretching.

There is an advantage to this when used with a micro that has hardware support - it means that the i2c hw itself waits for conversion completion rather than requiring the software to poll for it. The disadvantage is that the bus stays busy.

-adrian

steprog · 2009-09-24 09:33

I must have some sort of problem. I still can't seem to get the psoc to talk to i2cscantest. I have the address set to 0000 could that be an issue? I went into scantest to change the address scan to include zero but no luck.

I2C timing.

Comments