Trivial bug in(?) and proposed change to libi2c.h

Robert S. Grimes rsg at alum.mit.edu
Tue May 13 20:12:18 UTC 2008


Hi,

Two small issues in cpukit/libi2clib/libi2c.h:

1. On or about line 178, there is a small bug that causes my compiles to 
fail.  The relevant code is this:

    typedef struct rtems_libi2c_bus_ops_
    {
      /* Initialize the bus; might be called again to reset the bus
    driver */
      rtems_status_code (*init) (rtems_libi2c_bus_t * bushdl);
      /* Send start condition */
      rtems_status_code (*send_start) (rtems_libi2c_bus_t * bushdl);
      /* Send stop  condition */
      rtems_status_code (*send_stop) (rtems_libi2c_bus_t * bushdl);
      /* initiate transfer from (rw!=0) or to a device */
      rtems_status_code (*send_addr) (rtems_libi2c_bus_t * bushdl,
                                      uint32_t addr, int rw);
      /* read a number of bytes */
      int (*read_bytes) (rtems_libi2c_bus_t * bushdl, unsigned char *bytes,
                         int nbytes);
      /* write a number of bytes */
      int (*write_bytes) (rtems_libi2c_bus_t * bushdl, unsigned char *bytes,
                          int nbytes);
      /* ioctl misc functions */
      int (*ioctl) (rtems_libi2c_bus_t * bushdl,
            int   cmd,
    bug?==> void *buffer;
            );
    } rtems_libi2c_bus_ops_t;


Removing the ; at the end of "void *buffer;" makes my compiler happy.  
Is there any reason someone shouldn't make this change?

2.  Near the bottom of the same file, there is the typedef for 
rtems_libi2c_tfr_mode_t.  I'd like to add a new field to this structure 
as illustrated below (the new field is spi_sel_mode):

    typedef struct {
      uint32_t baudrate;       /* maximum bits per second               */
                               /* only valid for SPI drivers:           */
      uint8_t  bits_per_char;  /* how many bits per byte/word/longword? */
      boolean  lsb_first;      /* TRUE: send LSB first                  */
      boolean  clock_inv;      /* TRUE: inverted clock (high active)    */
      boolean  clock_phs;      /* TRUE: clock starts toggling at start
    of data tfr */
      boolean  spi_sel_mode;   /* SPI only - TRUE: SS set per
    transaction; */
                               /* FALSE: SS set per word */
    } rtems_libi2c_tfr_mode_t;


Justification: Some SPI devices want their chip select control signal to 
be "frame" each word (device-specific width), while others (such as some 
serial EEPROM and Ramtron FRAM devices) use the chip select as a 
"transaction" signal; in these devices, the chip select is made active, 
a command byte is sent, followed generally by a byte or two of address 
info, and finally one or more bytes of data to either write or (dummy) 
data to stimulate read data - the end of such a transaction is signaled 
by the CS going inactive.

Additionally, some SPI controllers, such as the Virtex SPI peripheral, 
can optionally generate automatic, per-word chip selects, or manual - 
thus supporting the per-word and per-transaction modes, respectively, 
mentioned above.

However, there is currently no mechanism for specifying to the SPI 
driver which strategy to use.  It is specific to the actual device on 
the SPI bus, so devices on one bus might well use different strategies.  
It seems the current SPI driver calls the ioctl function 
RTEMS_LIBI2C_IOCTL_SET_TFRMODE, which passes a pointer to a 
rtems_libi2c_tfr_mode_t structure; furthermore, initialization of SPI 
device-specific drivers (such as c/src/libchip/i2c/spi-flash-m25p40.c) 
provide the definition of said structure.  So this seems the right place 
to put it.

Does this sound like a good idea?  Can one of the gurus sponsor (or 
reject) this proposal?  FWIW - this is the approach I've adopted, and it 
seems to work just fine...

Thanks,
-Bob







More information about the users mailing list