Re: [Discuss-gnuradio] C++ daughterboard code

[Johnathan Corgan]

Eric Blossom wrote:

>> For the USRP1, then, there needs to be a method on usrp_standard_rx and
>> usrp_standard_tx classes that produces one of these callback objects.
> 
> I'm assuming that this is just a simple C++ class with virtual methods.

Yes, it would derive from a the hwa virtual base class and override the
methods and supply the relevant implementations.  The hwa_qa class is a
good example.

> At this stage in the game, the inband stuff is mostly about being able
> to send and receive frames at particular times, rather than being able
> to tweak for example the i2c inband.

Okay, if the underlying function call->USB->FX2->[I2C|SPI] paths are
still available, then a separate in-band hwa class isn't needed.

> Following up on Johnathan's post, I think the way forward is to create
> a new developer branch by copying the trunk, then merge Johnathan's
> diffs into that.  His branch is currently at least 2 months old.

It should merge fairly cleanly as a new top-level component, usrpdb.
There might be some interaction with the build system changes Michael
did about that time, though I think he made some changes directly in the
branch to avoid this.

> I would stick with the hardware abstraction (hwa_*).  We're going to
> need it very soon with the USRP2.  I really would like it done right
> the first time.

Agree.

> I don't think the instantiation framework is going to be any big deal
> in C++.  We basically just need to invoke the right daughterboard
> constructor based on the daughterboard ID feteched from the EEPROM.

>From the user API view, I think the usrp_standard_rx or usrp_standard_tx
classes should have a db() method that returns an array of instantiated
daughterboard shared pointers.  This allows non-GNU radio USRP users to
access all the hardware functionality of the motherboard and
daughterboards in a traditional function call environment.  This could
be a fixed-length array or an STL vector.

> We'll probably end up needing to move some of the code that's
> currently in usrp.py into new C++ methods that'll handle the "two
> stage tuning" calculations, etc.  Again, no big deal.

Thanks, Michael, for picking this up.