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. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
