discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] usrp2 windows port


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] usrp2 windows port
Date: Wed, 12 Aug 2009 13:40:06 -0700
User-agent: Mutt/1.5.18 (2008-05-17)

On Wed, Aug 12, 2009 at 10:11:30PM +0200, Michael Sprauer wrote:
> Am Sonntag, 9. August 2009 21:50:25 schrieb Eric Blossom:
> > On Sun, Aug 09, 2009 at 08:49:51PM +0200, Michael Sprauer wrote:
> > > Am Donnerstag, 6. August 2009 02:08:46 schrieben Sie:
> > >
> > > 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.
> 
> 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 ;-)

> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]