C++ daughterboard code [was MATLAB...]

On Wed, Apr 09, 2008 at 03:45:56PM -0400, Kevin Rudd wrote:

it and GNU Radio for several months. Unfortunately, it now sits in my
office unused. It is unfortunate, because I know how useful it can be.

I hope that one day I can use it for my needs.
Kevin

OK guys,

Thanks for all your comments re MATLAB.

I’m declaring the topic closed.

If somebody wants do do something useful that would forward the
action, 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.

Thanks again!

Eric

On Apr 9, 2008, at 4:56 PM, Eric B. wrote:

If somebody wants do do something useful that would forward the
action, 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.

I could be talked into doing that. It would benefit my current
efforts greatly. Please do send out (to the list, or me specifically)
your US$0.02 worth. - MLD

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

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

On Wed, Apr 09, 2008 at 02:48:50PM -0700, Johnathan C. wrote:

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.

the daughterboard code for correctness.
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

Michael D. wrote:

I could be talked into doing that. It would benefit my current efforts
greatly. Please do send out (to the list, or me specifically) your
US$0.02 worth. - MLD

Michael,

Are you still considering doing this? Is anyone out there interested in
taking this on? I can work on integrating this with the new in-band
code as progress is made. My efforts are kind of limited until late
May.

  • George

On Apr 20, 2008, at 11:25 PM, George N. wrote:

Michael D. wrote:

I could be talked into doing that. It would benefit my current
efforts greatly. Please do send out (to the list, or me
specifically) your US$0.02 worth. - MLD

Are you still considering doing this? Is anyone out there
interested in taking this on? I can work on integrating this with
the new in-band code as progress is made. My efforts are kind of
limited until late May.

George - Yes, I’m still considering … but, like you, I have limited
availability for the next few weeks or month - really depends on how
quickly my programming goes. I do hope that my programming drops off
a bit in the next couple of weeks so I can work on this branch. I’ve
looked over the code in Johnathan’s branch, and it looks pretty
straight forward what to do. I just haven’t had time to start doing
anything.

If anyone else is interested and more available, please feel free to
take this job. - MLD

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs