This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Request for comments onCYG_I2C_BITBANG_SCL_LOW_SDA_INPUT patch


>>>>> " " == 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]