[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 2.0.0.12 (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.
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.