discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] C++ daughterboard code [was MATLAB...]


From: Johnathan Corgan
Subject: Re: [Discuss-gnuradio] C++ daughterboard code [was MATLAB...]
Date: Wed, 09 Apr 2008 14:48:50 -0700
User-agent: Thunderbird 2.0.0.12 (X11/20080227)

Eric Blossom wrote:

> I suggest investing the effort required to convert the daughterboard
> code to C++.  Johnathan has looked at this, and may still have a
> developer branch around somewhere.  If you're interested in working
> on this, please post a note to the list, and Johnathan, Matt or I
> will give you our two cents worth about how we think it should work.


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.

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.

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]