I think $00 is "General Call" so you don't want to address your device as $00.
"Note 1: The general call address
This address is being used to access all devices on the bus which are capable of handling the general call and need this data. Devices which are capable of handling this general call but do not need it will not answer.
All bytes transferred after this address may or may not be taken in by the slaves that are responding to it. If no slave is acknowledging a transmitted byte, the operation is stopped by issuing a STOP on the bus.
The meaning of the general call address is specified in the 1st byte transmitted after this "general call". This first byte can contain the following information"
Post Edited (photomankc) : 9/24/2009 1:41:39 PM GMT
What pins are you using for I2C? Have you tried using the same pins as the EEPROM for your Cypruss device? Only do that if both lines have pull-up resistors though.
If you scan the boot I2C pins (29,28) and get back $A0 then at least you know the bus is working because that's the boot-EEPROM address. Then you can add in the other device and see if it responds.
The general call address may get responses from several devices so you don't want your address set to that and having multiple devices activated when you are really wanting to just talk to one.
The problem with address 0 is if there are multiple slave devices they might all try to respond since its a general call address. So I tend to avoid it. Strickly addresses < 10hex have special meaning though I have seen lego devices use address 8.
The i2cscan is looking for the ack to the address. So apart from the obvious issues of miswiring, here are some things to look at.
Are you configured on the psoc for 7 or 10bit addressing? - need to be 7bit.
Is the psoc powered off 3.3V or 5V? if its 5V have you inline resistors on the scl/sda lines? and pullups both sides of the inline resistors?
Can you tell if the psoc is getting a match on the address? It suggests in the psoc datasheet that an interrupt can be generated on a I2C address match are you seeing this?
@Peter & Adrian,
Adrian mentioned the MAX1139, and I use the similar MAX1238. I feel that if clock hold were not a part of the spec, someone would have to invent it. The clock hold allows high throughput. Once the chip mode is set up with an I2COUT, successive I2CIN commands can start successive conversions and immediately as part of the same I2CIN receive the result when hold is released. And no noise on the I2C line. It is true that the I2C line is disabled during that period, but it does not preclude sharing the I2C line with other peripherals, even if they are not hold-aware. One mode of conversion captures all 12 channels, or multiple samples of a single channel, in quick succession at about 8 µs per channel, then releases hold for readout of the 12 results. That is internal clocking. The ADC also has an external clocking mode that uses the I2C clock as the conversion clock for continuous streaming of results. By the way, the BS2p series all implement the clock hold capability.
I set it up using the ezi2c object. It uses 3.3v and Im pretty sure it's 7bit addressing I don't have any eyes into the psoc device to verify the interrupt. One thing I notice is that the i2cusb bridge sometimes will only receive FF's instead of valid values.
Peter Jakacki said...
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*
Forgive me, Peter, but I don't think that's correct.· Clock stretching is a means for a slow slave device to let the master know it must wait.
For example, suppose the I2C slave were a precision ADC that required several milliseconds to do a conversion (not unusual depending upon the accuracy and other requirements,·especially if one of the requirements is·extremely good differential linearity, which may require a dual-slope ADC), and the i2C bus were running at 100 KHz.· That slave would have to stretch the clock.· It couldn't possibly respond in a few tens of microseconds.· I2C is a very general interface, and some devices might conceivably have to stretch the clock for seconds or minutes.· There's nothing inherently wrong, or obsolete,·with that.
Carl,
The problem with using clock stretching as you describe is that it hangs up the bus until the slave is ready. A master may want to do something else with the bus while the device is doing its thing. Much better is for the device to have a status register indicating the progress of the operation. I think you'll find that at least some ADCs have one command that initiates a conversion and a status byte that indicates when the conversion is done and the data is ready to read. Often they're double buffered so the master reads the result of the last completed conversion. Most exceptions (that use clock stretching) have a short conversion time so the bus isn't monopolized for long, perhaps for one character time or several bit times.
Hi Guys,
Im confused. This may not be the right board for this, but here goes. I programmed my psoc to have address 6, 4, or 0. When I run the USB to I2C bridge. It can find the psoc at these addresses but only address 0 will display the correct integer values. non zero addresses give me ff's. Is there something in I2C that makes address 0 significant?
Try an addres like hex 20, it could be the psoc software checks for the special i2c address ranges which are < 10 hex and only allows 0 the general address to be used. Also try address 0 from the usb-i2c bridge when the psoc is set to a different address and see if it responds to the general call address anyway.
Also in i2cscan.spin line 25 ontains the address range that it scans
repeat i2cAddress from 1 to 127
if you change 1 to 0 it will scan address 0, you can see if the psoc reponds to the prop with address 0
nope same thing happens. If not 0 only ff's are read. Eventhough it can see the new address. The prop can't see the address at all no matter which it is. It does however find the eeprom on the dev board. I wouldn't think that the bridge would care what address it is but it does. Oh well I will keep digging. Im getting to hate I2C.
Mike Green said...
Carl,
The problem with using clock stretching as you describe is that it hangs up the bus until the slave is ready. A master may want to do something else with the bus while the device is doing its thing. Much better is for the device to have a status register indicating the progress of the operation. I think you'll find that at least some ADCs have one command that initiates a conversion and a status byte that indicates when the conversion is done and the data is ready to read. Often they're double buffered so the master reads the result of the last completed conversion. Most exceptions (that use clock stretching) have a short conversion time so the bus isn't monopolized for long, perhaps for one character time or several bit times.
Mike --
Undoubtedly your're right, and that's the way I'd design a slave too.· The 24LC256 we all know and love uses a different strategy; if it's busy it just doesn't send acknowledge bits.· Grrr.
But clock stretching apparently isn't rare.· If one isn't going to support it -- I don't support it in any code I've written -- one must first be sure that the particular devices one uses won't do it under the conditions one uses it.
I have encountered only·one I2c device -- can't remember what it was -- whose data sheet says it does clock stretching,·and my solution was simply to run it at less-than-maximum speed.· It works fine that way without support for clock stretching.
Might take a couple days break and come back to it. I swear there have been times when I was ready to pound the board to dust and walked away and then 3 days later I sit down, look, and say "Oh.... there's the problem". Honestly most of the I2C stuff I have played with was easy to get going. It might be worthwhile to mess around with some other I2C devices and see if you can work with them and then come back to the Cypruss once you have a bus that you know works top to bottom.
Debugging code and hardware at the same time always leads me to pulling hair out.
I just wanted to thank all you guys for helping me get my I2C to psoc interface working. I got it going the other night and wouldn't have been able to do it without all your help.
Again Thanks
The I2C spec doesnt list a minimum speed, but the spec sheets on the digital temp sensors i'm trying to read seem to in the spec sheets, which if i recall correctly, are SMBus compatable. TMP100 and TMP175 from ti.com in SOT23 and SO8 packages respectively. I'll need to read through the datasheets to see if they clock stretch, which may be a good indication why i cant even read a darn register.. when the datasheet lists 100MHz as a minimum for slow, that means the device wont respond well at slower speeds, right?
Mike
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Quicker answers in the #propeller chat channel on freenode.net. Don't know squat about IRC? Download Pigin! So easy a caveman could do it... http://folding.stanford.edu/ - Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
Post Edited (RinksCustoms) : 9/29/2009 2:05:24 PM GMT
RinksCustoms
I have tried a SMBus device MLX90614, its min speed was 20KHz and found it reset and wouldn't talk on the I2C bus any long if I failed the timing. Looking at the spec for TMP175 its min speed is 1KHz. Try the I2CScan in this thread, it is fast enough for the MLX90614 so should meet the min timing of the TMP175.
Hi PhotoMankc
It took some ot that time stretching that Timmoore sent me. I used the write when looking for the devicepresent routine. After that used the normal readlocation routines to pick up the data. I also set the psoc for pullups instead of open collector outputs. I believe it was the write in the device present routine that did the trick. I haven't gone back to isolate each change to see which did it yet. Right now just happy to be making progress. I got a lot of work to do.
Timmoore said...
RinksCustoms
I have tried a SMBus device MLX90614, its min speed was 20KHz and found it reset and wouldn't talk on the I2C bus any long if I failed the timing. Looking at the spec for TMP175 its min speed is 1KHz. Try the I2CScan in this thread, it is fast enough for the MLX90614 so should meet the min timing of the TMP175.
Thanks for the advice, i'll give it a whirl, also try to implement a waitpeq on the clock in case the slave is stretching clocks. If i can get the TMP100 sensors to work (sot23), i can then j-b weld them into the bottom of drilled out bolts to get temp data of the engine/trans in my Prop based D.F.I. system. i thought procuring the Mass airflow data was difficult...
Michael
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Quicker answers in the #propeller chat channel on freenode.net. Don't know squat about IRC? Download Pigin! So easy a caveman could do it... http://folding.stanford.edu/ - Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
Post Edited (RinksCustoms) : 9/29/2009 9:45:36 PM GMT
Comments
"Note 1: The general call address
This address is being used to access all devices on the bus which are capable of handling the general call and need this data. Devices which are capable of handling this general call but do not need it will not answer.
All bytes transferred after this address may or may not be taken in by the slaves that are responding to it. If no slave is acknowledging a transmitted byte, the operation is stopped by issuing a STOP on the bus.
The meaning of the general call address is specified in the 1st byte transmitted after this "general call". This first byte can contain the following information"
Post Edited (photomankc) : 9/24/2009 1:41:39 PM GMT
If you scan the boot I2C pins (29,28) and get back $A0 then at least you know the bus is working because that's the boot-EEPROM address. Then you can add in the other device and see if it responds.
The general call address may get responses from several devices so you don't want your address set to that and having multiple devices activated when you are really wanting to just talk to one.
The i2cscan is looking for the ack to the address. So apart from the obvious issues of miswiring, here are some things to look at.
Are you configured on the psoc for 7 or 10bit addressing? - need to be 7bit.
Is the psoc powered off 3.3V or 5V? if its 5V have you inline resistors on the scl/sda lines? and pullups both sides of the inline resistors?
Can you tell if the psoc is getting a match on the address? It suggests in the psoc datasheet that an interrupt can be generated on a I2C address match are you seeing this?
Adrian mentioned the MAX1139, and I use the similar MAX1238. I feel that if clock hold were not a part of the spec, someone would have to invent it. The clock hold allows high throughput. Once the chip mode is set up with an I2COUT, successive I2CIN commands can start successive conversions and immediately as part of the same I2CIN receive the result when hold is released. And no noise on the I2C line. It is true that the I2C line is disabled during that period, but it does not preclude sharing the I2C line with other peripherals, even if they are not hold-aware. One mode of conversion captures all 12 channels, or multiple samples of a single channel, in quick succession at about 8 µs per channel, then releases hold for readout of the 12 results. That is internal clocking. The ADC also has an external clocking mode that uses the I2C clock as the conversion clock for continuous streaming of results. By the way, the BS2p series all implement the clock hold capability.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
For example, suppose the I2C slave were a precision ADC that required several milliseconds to do a conversion (not unusual depending upon the accuracy and other requirements,·especially if one of the requirements is·extremely good differential linearity, which may require a dual-slope ADC), and the i2C bus were running at 100 KHz.· That slave would have to stretch the clock.· It couldn't possibly respond in a few tens of microseconds.· I2C is a very general interface, and some devices might conceivably have to stretch the clock for seconds or minutes.· There's nothing inherently wrong, or obsolete,·with that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
The problem with using clock stretching as you describe is that it hangs up the bus until the slave is ready. A master may want to do something else with the bus while the device is doing its thing. Much better is for the device to have a status register indicating the progress of the operation. I think you'll find that at least some ADCs have one command that initiates a conversion and a status byte that indicates when the conversion is done and the data is ready to read. Often they're double buffered so the master reads the result of the last completed conversion. Most exceptions (that use clock stretching) have a short conversion time so the bus isn't monopolized for long, perhaps for one character time or several bit times.
Im confused. This may not be the right board for this, but here goes. I programmed my psoc to have address 6, 4, or 0. When I run the USB to I2C bridge. It can find the psoc at these addresses but only address 0 will display the correct integer values. non zero addresses give me ff's. Is there something in I2C that makes address 0 significant?
Also in i2cscan.spin line 25 ontains the address range that it scans
repeat i2cAddress from 1 to 127
if you change 1 to 0 it will scan address 0, you can see if the psoc reponds to the prop with address 0
Undoubtedly your're right, and that's the way I'd design a slave too.· The 24LC256 we all know and love uses a different strategy; if it's busy it just doesn't send acknowledge bits.· Grrr.
But clock stretching apparently isn't rare.· If one isn't going to support it -- I don't support it in any code I've written -- one must first be sure that the particular devices one uses won't do it under the conditions one uses it.
I have encountered only·one I2c device -- can't remember what it was -- whose data sheet says it does clock stretching,·and my solution was simply to run it at less-than-maximum speed.· It works fine that way without support for clock stretching.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Might take a couple days break and come back to it. I swear there have been times when I was ready to pound the board to dust and walked away and then 3 days later I sit down, look, and say "Oh.... there's the problem". Honestly most of the I2C stuff I have played with was easy to get going. It might be worthwhile to mess around with some other I2C devices and see if you can work with them and then come back to the Cypruss once you have a bus that you know works top to bottom.
Debugging code and hardware at the same time always leads me to pulling hair out.
Again Thanks
Mike
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Quicker answers in the #propeller chat channel on freenode.net. Don't know squat about IRC? Download Pigin! So easy a caveman could do it...
http://folding.stanford.edu/ - Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
Post Edited (RinksCustoms) : 9/29/2009 2:05:24 PM GMT
I have tried a SMBus device MLX90614, its min speed was 20KHz and found it reset and wouldn't talk on the I2C bus any long if I failed the timing. Looking at the spec for TMP175 its min speed is 1KHz. Try the I2CScan in this thread, it is fast enough for the MLX90614 so should meet the min timing of the TMP175.
It took some ot that time stretching that Timmoore sent me. I used the write when looking for the devicepresent routine. After that used the normal readlocation routines to pick up the data. I also set the psoc for pullups instead of open collector outputs. I believe it was the write in the device present routine that did the trick. I haven't gone back to isolate each change to see which did it yet. Right now just happy to be making progress. I got a lot of work to do.
Thanks for the advice, i'll give it a whirl, also try to implement a waitpeq on the clock in case the slave is stretching clocks. If i can get the TMP100 sensors to work (sot23), i can then j-b weld them into the bottom of drilled out bolts to get temp data of the engine/trans in my Prop based D.F.I. system. i thought procuring the Mass airflow data was difficult...
Michael
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Quicker answers in the #propeller chat channel on freenode.net. Don't know squat about IRC? Download Pigin! So easy a caveman could do it...
http://folding.stanford.edu/ - Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
Post Edited (RinksCustoms) : 9/29/2009 9:45:36 PM GMT