I2C support?

[kbanks]

This came in as an email, posted on the forum on behalf of the customer

We are looking to interface with Dallas 1-wire devices and you recently suggested the DS2482 i2c to 1-wire bridge. This will work for our purposes.

Looking through the documentation and the user manual I don't see any way to specifically address the i2c bus. I think this functionality may only be available in the beta versions of the software. Is this right? Can you provide some documentation on how I would access the i2c bus from within Python? Typically I access the i2c bus from the pic using i2c_initialize, i2c_read and i2c_write functions and I assume that there is something similarly available in python.

Thanks,

Tom Johnson
Controls Plus USA


You are correct, i2c support was not in the 2.0 release, but it has been implemented for the upcoming 2.1 release (as has SPI and CBUS).

In all three cases (i2c, SPI, and CBUS), the RF Engine has to be the "bus master".

We haven't had a chance to update the SNAP Reference Manual yet, but here are the new functions for i2c:

i2cInit(pullups) - setup for I2C, with internal (True) or external (False) pullup resistors

i2cWrite(byteStr,retries,ignoreFirstAck) - send data out I2C - returns bytes actually sent

i2cRead(byteStr,numToRead,retries,ignoreFirstAck) - send data out I2C then read response - returns response string

getI2cResult() - returns status code from most recent I2C operation

As a placeholder until we are able to switch from working on code to working on docs, I have attached some example scripts that USE the new i2c capabilities. If you are familiar with i2c, these example scripts should clarify the usage of the new functions.

i2ctests.py - the overall script
CAT24C128.py - example of using an i2c serial EEPROM
M41T81.py - example of using an i2c clock/calendar chip

[riddhi.kanabar]

Hi,
I am confused with the i2cwrite function. what so the parameters in the i2cwrite represent. is str the data which is being wirtten and if yes, which is the memory location where str is being stored?
Thank You,
Riddhi Kanabar

[kbanks]

Yes, parameter byteStr is the string that will be written out to the I2C bus.

It could be a constant string, or a dynamic string. It's location in memory is irrelevant.

[hardtootell]

I am using the EK2100 kit to try to read and write to an I2C eeprom.

I am using SN171 protoboard GPIO17 to the SDA on the EEPROM and GPIO18 to the SCL on the EEPROM.

I have tried the CAT24C128 python script and the i2ctests.py script.

I always use chip address 0, memory address 100 and enter a 3 digit integer.

With both the Event Log indicates that I have written to the chip but when I go to read I get

FF FF FF FF when I use the I2Ctests.py and
yyyyyyyyyyyyyyyyyy when I use the CAT24C128.py

There are only 4 connections between the protoboard and the 8 DIP chip.
I have triple checked the connections. I am new at Python but have done this a few times in C...:confused:
Does anyone know what is going on with this?:confused:
thanks in advance HHT

[Jheath]

The behavior/details of these example scripts are specific to the CAT24C128 chip (most notably the device address). Which device are you using? Does it require you to ignore the first ACK (see I2CRead function parameters in the SNAP Reference Manual)?

Note: The datasheets from some I2C chips do not shift the value by one byte when they list the device address, while some do.
Example: Address of 0x50 might be 0x50 for a write and 0x51 for a read or 0xA0 for a write and 0xA1 for a read - it all depends on how they list things.

[Jheath]

I'll also make note of the fact the SNAP device must be the master of the I2C interactions.

[vks_01]

Something to note: the SNAPpy builtin I2C routines do not support a Restart condition. If you device requires a Restart, you will have to write a custom script. I have used the one that I found on the forum which was a bit-banged I2C routine which had the Restart included and that worked like a charm.

Karthik

[topazx2]

Also good to note for those of you who are not very experienced with I2C interfaces:
Internal pull-ups are generally considered a bad idea since I2C SDA & SCL pins are "floating" on most peripherals and internal pull-ups in the radio only act on the input side of the communication, not the output.
So if you're using something like a DS1337 RTC which does not have internal SDA and SCL pull ups, you will experience random failures that will drive you crazy.

Most peripherals do not have internal pull ups, so they require external pull ups which negate the need for internal pull ups on the radio end.