[Top][All Lists]

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

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

From: Johnathan Corgan
Subject: Re: [Discuss-gnuradio] C++ daughterboard code
Date: Wed, 09 Apr 2008 15:36:59 -0700
User-agent: Thunderbird (X11/20080227)

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.


> 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.

reply via email to

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