Re: About EEPROM and FX2(68013a) USB interface in USRP

On Mon, Apr 12, 2010 at 12:00 PM, [email protected]
wrote:

I am developing a board with gnuradio which is like USRP. It is also use
FX2LP(CY7C68013a) and AD9862, and I add some surroundings.

I hope that my board can work well with gnuradio, but it seems like it can
only support USRP now. So could you please give me some help, if I want to
run gnuradio on my board. How should I do with it?
ThinkRF (www.thinkrf.com) is also developing GNU Radio compatibility
for its product. I have been working on this project for a few months.
We’re interested in feedback on the approach we took.

Our board is also an unconfigured Cypress FX2 on power-up, so we will
have a proprietary utility that changes the personality of the board.
Once that is done, the board “looks” like a USRP, presenting the
corresponding VID/PID and responding to the USRP USB protocol.

We chose to have it show up as a USRP “rev 5” to distinguish it from a
real USRP, of which I believe the latest revision is 4. Is this likely
to conflict any time soon?

One of our goals was to minimize the changes required to the GNU Radio
source tree, to make deployment and maintenance easier and to increase
the chances of changes being integrated upstream.

Catalin

On 04/13/2010 03:32 PM, Catalin P. wrote:

real USRP, of which I believe the latest revision is 4. Is this likely
to conflict any time soon?

I would have used a higher version number, in order to give Ettus
more “headroom” for new versions of their hardware, as an item
of courtesy. In fact, Matts a great guy, you should perhaps just
work this out between you, so that no “tripping over each other”
happens, and the marketplace doesn’t end up with down-the-road
grief.

I’m all in favour of standardizing the “wire” protocols used by
both the USRP1 and USRP2, actually.

One of our goals was to minimize the changes required to the GNU Radio
source tree, to make deployment and maintenance easier and to increase
the chances of changes being integrated upstream.

A laudable goal, and I encourage cooperation, and the development of
wire
standards in this area. Full-disclosure: I used to be a protocol
standards
expert for my previous employer, Nortel. So I’m biased :slight_smile:


Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

Catalin-

Hi All

Our board is also an unconfigured Cypress FX2 on power-up, so we will
have a proprietary utility that changes the personality of the board.
Once that is done, the board “looks” like a USRP, presenting the
corresponding VID/PID and responding to the USRP USB protocol.

We chose to have it show up as a USRP “rev 5” to distinguish it from a
real USRP, of which I believe the latest revision is 4. Is this likely
to conflict any time soon?

My suggestion would be to use 4.x and work out with Matt what the x
should be… for example you might use 4.6 if Matt
says that he’s likely to jump a major rev number before he moves the
minors to 4.5 This would give the advantage of
“marking” your board with a more-or-less accurate time-frame and
capabilities range.

-Jeff

On Tue, Apr 13, 2010 at 03:32:49PM -0400, Catalin P. wrote:

Hi All

Our board is also an unconfigured Cypress FX2 on power-up, so we will
have a proprietary utility that changes the personality of the board.
Once that is done, the board “looks” like a USRP, presenting the
corresponding VID/PID and responding to the USRP USB protocol.

I suggest (following Cypress’s lead) that you have your device come
up as something other than an unconfigured Cypress FX2.

Eric

On 04/13/2010 07:09 PM, Jason U. wrote:

This seems like it can only cause problems down the line. Wouldn’t it
be better from a development point of view to keep your device as a
separate VID/PID that is unique to you and simply abstract/link the
existing USRP functions into your source/sink pair?

A couple of comments. Yup, a separate VID/PID (although doesn’t Ettus
use
a VID assigned to the FSF, in order to avoid large fees paid to the
USB
consortium or something? ) would be a good idea.

If the device really does, more, or less, look like a USRP, then the
right thing
to do is to have a table in the USRP code (there probably already is)
that
looks for the various VID/PID that could be a USRP-type device, and
“do the right thing” (configuring itself for vendor-a whizzy feature,
etc).

What I’d like to see is cooperation on these sorts of things from the
various
vendors in the new “eco-system” that Matt has unwittingly created
here.

Creating some kind of cooperative standard for how the USB and GiGE
interfaces
work (with provision for vendor-specific-whizzy-stuff) will make
everybodies lives
easier. It will be an ecosystem, rather than a bunch of independent
bunkered
silos.

This way, at a minimum, if the USRP code were changed someway that
broke your fpga implementation, the graph would fail gracefully, as
opposed to the host just happily sending samples along while your
device does nothing. Not to mention this would give you the ability
to extend the functionality of the source/sink pair to take advantage
of anything your board happens to do better than the USRP. From your
website it seems that you support a wider bandwidth and frequency
range than the USRP, why limit your board?

I haven’t looked at the wire protocol for either the USB or 1GiGE side
of things,
but it wouldn’t surprise me if the wire protocols were fairly agnostic
about
things like bandwidth. I mean the protocols already have to support
notions
of “capabilities” with all the new daughter-cards out there.

Which brings up an interesting question. Is the “capabilities database”
on the cards,
or in the driver code, or in the FPGA code, or what? Is it rather a
mix?

I like this to other “classes” of USB devices, like USB Audio, where
there is a “base”
protocol and expected device behaviour, and custom variants for
operating outside
the base functionality.

No reason not to do something similar here, both for USB and 1GiGE, and
whatever else
comes along in the future.

Despite that fact that (full disclosure) I derive a small part of my
income through Ettus, I’m thrilled
to see a USRP{1,2}-based “ecosystem” developing out there. It’s
healthy for everybody. Not
just in the traditional “competition is good business” sense, but
because it causes better, more
mature growth. Applications can run on different hardware without
being re-written, new hardware
can instantly take advantage of existing applications. It’s just a
Good Thing™.

These are exciting times in the SDR world, I believe.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

On Tue, Apr 13, 2010 at 5:06 PM, Eric B. [email protected] wrote:

I suggest (following Cypress’s lead) that you have your device come
up as something other than an unconfigured Cypress FX2.
Eric, would you be able to assign a temporary PID to us under the FSF
VID? We are working toward USB certification but we would like to have
something to work with in the meantime. I mentioned this to Matt and
he feels that this would be a good way to handle this.

Note that we will release all our modifications to the USRP USB
firmware and FPGA code, as per the GPL.

Thanks

On Tue, Apr 13, 2010 at 4:06 PM, Eric B. [email protected] wrote:

corresponding VID/PID and responding to the USRP USB protocol.
This seems like it can only cause problems down the line. Wouldn’t it
be better from a development point of view to keep your device as a
separate VID/PID that is unique to you and simply abstract/link the
existing USRP functions into your source/sink pair?

This way, at a minimum, if the USRP code were changed someway that
broke your fpga implementation, the graph would fail gracefully, as
opposed to the host just happily sending samples along while your
device does nothing. Not to mention this would give you the ability
to extend the functionality of the source/sink pair to take advantage
of anything your board happens to do better than the USRP. From your
website it seems that you support a wider bandwidth and frequency
range than the USRP, why limit your board?

Jason

On Wed, Apr 14, 2010 at 02:06:19PM -0400, Catalin P. wrote:

Thanks

Done.
Committed as da8ebdb30509c07718b10b642e2b4250aa45b1d8

#define USB_PID_FSF_THINKRF 0x0015 // Catalin P.
[email protected]

Eric

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