[ECOS] Request for comments onCYG_I2C_BITBANG_SCL_LOW_SDA_INPUT patch
Bart Veer
bartv@ecoscentric.com
Fri Mar 10 21:20:00 GMT 2006
>>>>> " " == Newsgroups Reader <mail_lists@telus.net> writes:
> I do have an issue with the I2C stuff. Some of the (larger?)
> I2C eeproms use parts of the I2C device address mixed with the
> read/write address to...er...address(!) the location within the
> device to read/write.
> The way it works now, my I2C eeprom has to appear as 4
> different I2C devices. It kinda sucks! I think the I2C bus
> should be defined/abstracted as is, but the actual I2C devices
> shouldn't be. I guess this would mean passing around an I2C
> device address to the functions, but at least you would be able
> to generate I2C device addresses "on the fly".
That is one approach, and a perfectly valid one. Another approach is
to encapsulate the EEPROM accesses in a little API, e.g.:
static CYG_I2C_DEVICE(at24c04, <bus>, 0x50, 0, CYG_I2C_DEFAULT_DELAY);
static cyg_drv_mutex_t eeprom_lock;
void
eeprom_read(int offset, cyg_uint8* buf, int len)
{
cyg_drv_mutex_lock(&eeprom_lock);
if (offset >= 256) {
at24c04.i2c_address |= 0x01;
offset -= 256;
} else {
at24c04.i2c_address &= ~0x01;
}
// Now perform standard i2c operations on dev at24c04.
// Offset < 256, the device address is set appropriately
cyg_drv_mutex_unlock(&eeprom_lock);
}
There is nothing in the I2C API that requires the device instances to
be read-only. With some EEPROM devices care will have to be taken if a
transfer crosses a 256-byte boundary, e.g. setting the I2C address
inside a loop.
Obviously with most I2C devices there is no need to mess about with
the address like that. Hence it can be kept fixed in the
cyg_i2c_device structure, simplifying the API for higher-level code.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss
mailing list