i2c start and stop conditions

Allan Hessenflow allanh-rtems2 at kallisti.com
Sat Jan 24 17:39:31 UTC 2009


On Fri, Jan 23, 2009 at 16:12:51 -0600, Joel Sherrill wrote: 
> Paul Evans wrote:
> > he i2c "start" and "stop" conditions are manually controlled by the 
> > RTEMS libi2c code, unfortunatly our i2c controller like most I guess-- 
> > generates these conditions itself as part of normal framing. Our device 
> > driver has to queue up a "start/data/stop" sequence and strip off the 
> > start and stop before activating the hardware. This reminds me of trying 
> > to use termios to control a UART that does packeting operations..
> How can we best handle this? 

I saw the same thing with the Blackfin I2C hardware.  So I decided to
write the Blackfin I2C driver to take a higher level transaction than
libi2c uses.  I had not yet decided whether to try to add a layer to fool
libi2c into thinking it is controlling the lower level operations, but I
think the ideal solution would be to standardize a higher level interface
and migrate libi2c clients to that.  Existing libi2c drivers would not
need to be ported since the code to go from the higher level i2c
requests to libi2c requests would be fairly simple.  I seem to recall
libi2c might use different terminology; by driver I mean the code that
talks to the i2c interface, and an eeprom driver would be a libi2c
client.

FYI, here's the interface I'm using at the moment (not including
initialization and a hook for supporting i2c slave operations):

typedef struct bfin_twi_request_s {
  bool write;
  int count;
  void *data;
  /* Chained requests are done with repeated start conditions in between.
     These are useful for atomic address write/data read transactions
     (which can be important in multi-master configurations), and for
     doing 10-bit addressing. */
  struct bfin_twi_request_s *next;
} bfin_twi_request_t;

rtems_status_code bfin_twi_request(int channel, uint8_t address,
                                   bfin_twi_request_t *request,
                                   rtems_interval timeout);

So, a single request structure corresponds to an i2c read or write 
operation.  A single call to bfin_twi_request corresponds to a single
atomic i2c operation (which can be a read, a write, or a combination
using repeated starts in between).  The above is a synchronous
interface; async could of course be done with the addition of some
mechanism to indicate a transaction is complete (and it's status).

allan

-- 
Allan N. Hessenflow      allanh at kallisti.com



More information about the users mailing list