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

[Eric Blossom]

On Wed, Apr 09, 2008 at 02:48:50PM -0700, Johnathan Corgan wrote:
> 
> There is a developer branch:
> 
> http://gnuradio.org/trac/browser/gnuradio/branches/developers/jcorgan/usrpdb
> 
> This branch has implemented the framework for a C++ implementation of
> all the daughterboards, and several boards already implemented, but with
> a twist--it is designed to be used unchanged with both USRP1 and USRP2.
>  The daughterboard C++ code itself is very straightforward.
> 
> The key concept is abstracting out the USRP motherboard specific actions
> (e.g., set_pga_gain, write_i2c_register, etc.) which work via completely
> different underlying mechanisms between USRP1 and USRP2.  The
> constructor for the daughterboard class takes a pointer an "hwa" object
> that encapsulates the differences between these environments, and the
> daughterboard class makes callbacks on this object to get things done.
> 
> 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.

> For USRP1 with in-band signaling, there might need to be a different hwa
> object; I'm not sure as I'm not familiar with the code and whether it
> uses usrp_standard_*x underneath or replaces them.

I think for a first pass, it can be the same as the existing USRP.
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.

> For USRP2, we will write the hardware access layer to abstract out the
> technique for accessing all the functionality over the Ethernet.
> 
> (From the user API perspective, they won't see this hwa object, because
> the USRP daughterboard instantiate framework will handle it for him.)
> 
> Once these hardware access shims are written, all the daughterboard code
> is usable unchanged, since it just making callbacks to the abstraction
> layer.  In fact, there is a "hwa_qa" class now, which provides stubs for
> all the hwa methods and is used in the QA unit testing framework to test
> the daughterboard code for correctness.
> 
> Once that is working, there is still the issue of migrating the
> Python-based daughterboard instantiation framework.  It currently uses
> some clever Python coding to auto-detect the type of daughterboards
> connected to a USRP, then populate the usrp.db[][] database as
> appropriate.  But it is doing it using features available in a
> late-binding, non-compiled language.  The net is that none of this code
> will port to C++, the feature has to be written from scratch in C++.
> 
> I have started it, but don't have time to finish it.  I do think it is
> far enough along that someone can pick it up and I'm willing to help
> them to do so.  Or, if someone wants to do a USRP1-only C++
> implementation and rewrite major portions of it for USRP2, that's okay too.

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.

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.

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.

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.

After you get a chance to look at the existing work-in-progress, let
me know if you've got more questions.

Eric