Re: [Discuss-gnuradio] more issues with read_i2c

[Jared Jensen]

D'oh!  Typo.  I'm actually on Side A, not B, and am using 0x67.  Since 
posting this, I started debugging and put in some debug statements in 
usrp_prims.cc and rebuilt with make && make install.  The issue was just 
byte-ordering in the data buffer.  I had guessed wrong as to how python 
marshals data to/from C strings.  Thanks for the help.

j0j


> From: Eric Blossom <address@hidden>
> To: Jared Jensen <address@hidden>
> CC: address@hidden
> Subject: Re: [Discuss-gnuradio] more issues with read_i2c
> Date: Mon, 30 Jul 2007 15:44:13 -0700
>
> On Mon, Jul 30, 2007 at 12:44:11PM -0400, Jared Jensen wrote:
> > I've been having some issues with read_i2c.  I noticed several posts 
> dealt
> > with this, and their particular solutions didn't resolve the issue, so 
> here
> > it goes.
> >
> > I ported bd_bds_rx.py and bd_basic.py to C++, along with usrp.py so I 
> could
> > include it all in my C++ signal processing app.  Things in general work,
> > but read_i2c doesn't.  I'm using a dbsrx on side B and using I2C_ADDR =
> > 0x67.  I called _write_oe(0,0x0001,0x0001) and not write_io(...).
>
> class db_dbs_rx (db_base.db_base):
>     def __init__ (self, usrp, which):
>         """
>         Control DBS receiver based USRP daughterboard.
>
>         @param usrp: instance of usrp.source_c
>         @param which: which side: 0 or 1 corresponding to RX_A or RX_B 
> respectively
>         @type which: int
>         """
>         # sets _u and _which
>         db_base.db_base.__init__(self, usrp, which)
>
>         self._u._write_oe(self._which,0x0001,0x0001)
>         self.i2c_addr = (0x67, 0x65)[self._which]
>
> 0x65 is the i2c_address for a DBSRX on the B side.
> FWIW, 0x67 is for the A side.
>
> Eric

_________________________________________________________________
http://liveearth.msn.com