Usrp2 windows port

GNU Radio
1

Hello list,

is someone working on a port of the usrp2 stuff to pcap lib so it can
run on
windows as well as on linux?
I’m fighting in this area right now. Are there some things to know? What
does
the core-devs think? Is it possible?

kind regards
Michael

2

On Wed, Aug 05, 2009 at 11:48:03PM +0200, Michael Sprauer wrote:

Hello list,

is someone working on a port of the usrp2 stuff to pcap lib so it can run on
windows as well as on linux?

Not that I know of. As you’ve probably noticed, the current
implementation uses linux-specific code to map the buffers into user
space. It should be possible to get a similar result using pcap.

I’m fighting in this area right now. Are there some things to know? What does
the core-devs think? Is it possible?

I can barely spell “windows”, but if you know how to get raw ethernet
frames into and out of user space on windows, you can probably make it
work. Let me know how it goes.

Eric

3

Am Donnerstag, 6. August 2009 02:08:46 schrieben Sie:

late fall 2009 or so.

  John

So does it make sense to rewrite it for pcap lib?

I finally managed to compile it with basic functionality. Now I’m trying
to
communicat with the box somehow. More news on this will follow next
week.

I had an issue with the gr-usrp2 python stuff. With the
std::vector<uint32_t>
to be more precise. Sometimes uint32_t is an unsigned int and sometimes
an
unsigned long. But I guess unsigned long is the intended type.

For now I did not dare to try grc yet. But this will surely be my next
topic.
btw: I’m working on cygwin.

Michael

4

For now I did not dare to try grc yet. But this will surely be my next topic.
btw: I’m working on cygwin.

grc is all python, it will work on cygwin so long as you can get python
2.5 and pygtk installed (which is the real challenge).

You may have better luck with mingw which can use the native windows
python and pygtk/gtk packages.

-Josh

5

On Sun, Aug 09, 2009 at 08:49:51PM +0200, Michael Sprauer wrote:

to using UDP packets to/from the USRP2. I think that’s scheduled for
late fall 2009 or so.

  John

So does it make sense to rewrite it for pcap lib?

Your call. Under Linux, the current system works.
When we move to UDP, it ought to be relatively straight-forward to get
it running well on pretty much any platform.

I finally managed to compile it with basic functionality. Now I’m trying to
communicat with the box somehow. More news on this will follow next week.

I had an issue with the gr-usrp2 python stuff. With the std::vector<uint32_t>
to be more precise. Sometimes uint32_t is an unsigned int and sometimes an
unsigned long. But I guess unsigned long is the intended type.

I think you misunderstand the purpose of the explicit sized typedefs
in stdint.h. When we ask for a uint32_t we want an unsigned 32-bit
integer. We don’t care what it’s called. We care very much about its
size, since it’s part of the specification of the on-the-wire format.

Eric

6

Am Sonntag, 9. August 2009 21:50:25 schrieb Eric B.:

should become much easier to interface when the project switches over

in stdint.h. When we ask for a uint32_t we want an unsigned 32-bit
integer. We don’t care what it’s called. We care very much about its
size, since it’s part of the specification of the on-the-wire format.

I’m pretty sure I didn’t get the point of this typedefs. But my gcc
compiler
didn’t grasp it either. But unsigned int and unsigned long are both
4bytes, at
least on my Win32 XP-System so maybe it’s not to wired. Maybe I find
some time
to track it down once I finished the other parts.

Today a had the “first contact” with the USRP2 via ethernet. But I
realized,
that I’d have to rewrite major parts of the memory handling in the
receiving
part as kernel buffer is not supported by pcap. I’d suggest to rewrite
it
completely so that the linux part is also using the pcap-lib for better
code
maintenance.
What is your opinion?

Michael

7

On Wed, Aug 12, 2009 at 10:11:30PM +0200, Michael Sprauer wrote:

in stdint.h. When we ask for a uint32_t we want an unsigned 32-bit
integer. We don’t care what it’s called. We care very much about its
size, since it’s part of the specification of the on-the-wire format.

I’m pretty sure I didn’t get the point of this typedefs. But my gcc compiler
didn’t grasp it either. But unsigned int and unsigned long are both 4bytes, at
least on my Win32 XP-System so maybe it’s not to wired. Maybe I find some time
to track it down once I finished the other parts.

It’s OK that unsigned int and unsigned long are both 4 bytes int.
On many (most?) 64-bit machines running 64-bit OS’s int is 32-bit and
long is 64-bits. If we wanted 64-bits we would have used int64_t :wink:

Today a had the “first contact” with the USRP2 via ethernet. But I realized,
that I’d have to rewrite major parts of the memory handling in the receiving
part as kernel buffer is not supported by pcap. I’d suggest to rewrite it
completely so that the linux part is also using the pcap-lib for better code
maintenance.
What is your opinion?

Part of the problem with pcap is that you never know what it’s doing
behind the scenes. The way we’ve written the current code, we know
what’s going on, and are pretty sure there’s no faster way to get
packets out, including jumbos if we wanted them too.

I should be possible to have the pcap version exist in parallel in the
code base.

When we move to UDP, I don’t think we’ll need pcap.

Eric