Hi All

I am building UHD 3.4.2 from last stable release, under Windows 7 64bit, VS
2008, using boost 1.49.0 (compiled it myself)
To get UHD 64 bit debug, I've done :
_ applied patch described here :
http://comments.gmane.org/gmane.comp.hardware.usrp.e100/3420
(without this patch, there are some DLL load problems)
_ in Cmake

• Release to Debug
• set path to boost lib
• changed /machine:X86 to /machine:X64 (3 rows)
• changed /Dwin32 flags to /Dwin64 (2 rows)
  _ changed active platform from win32 to x64 in VS (and this for all
  sub-projects)
  _ ALL_BUILD -> build UHD compiles and link fine
  _ INSTALL -> build, the bin folder is not copied to the target
  _ I copy uhd.dll manually, and uhd_find_devices.exe

running uhd_find_devices.exe gives :

C:\Program Files\UHD>uhd_find_devices.exe
Win32; Microsoft Visual C++ version 9.0; Boost_104900;
UHD_003.004.002-0-unknown

No UHD Devices Found

C:\Program Files\UHD>pause
Press any key to continue . . .

while when I'm trying with an older build, 32 bits, the device is found :

C:\Program Files (x86)\UHD_3_3_1_vc9_debug\bin>uhd_find_devices.exe
Win32; Microsoft Visual C++ version 9.0; Boost_104700;
UHD_003.003.001-unknown

-- UHD Device 0

Device Address:
type: usrp2
addr: 192.168.10.3
name:
serial:

C:\Program Files (x86)\UHD_3_3_1_vc9_debug\bin>pause
Press any key to continue . . .

My questions are :
_ why device is not found with 64 bit version ?
_ How can I avoid setting manually x64 for each sub-project in VS 2008 ?
_ Why 64 bit version still prints Win32 on the command line ? Should I just
ignore that ?
_ What is the patch applied really doing ?

Thanks and Regards
Bastien

Hi,

Over the last two weeks I've been through the Windows 64-bit integration
process. In my case I'm using the latest unstable Debug and Release builds.

I used VS2010

I built Boost from source

I have to use shared CTRL and MFC in the executable because UHD.dll can only
be used this way

I am now able to use UHD.dll and ship to my software commercial customers
without worrying about the USRP support issues. I'm able to get a reliable
20MHz bandwidth using complex floats from a WBX board with a 2.8GHz CPU
(i7).

Simon Brown, HB9DRV
http://dit-dit-dit.com/ http://dit-dit-dit.com

You are standing at the end of a road before a small brick building. Around
you is a forest.

A small stream flows out of the building and down a gully. The sunspot count
is 285.

From: usrp-users-bounces@lists.ettus.com
[mailto:usrp-users-bounces@lists.ettus.com] On Behalf Of Bastien Auneau
Sent: 07 June 2012 16:14
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Windows 7 64 bit build issues : bin folder is not
copied by INSTALL build, USRP not found

Hi All

I am building UHD 3.4.2 from last stable release, under Windows 7 64bit, VS
2008, using boost 1.49.0 (compiled it myself)
To get UHD 64 bit debug, I've done :
_ applied patch described here :
http://comments.gmane.org/gmane.comp.hardware.usrp.e100/3420
(without this patch, there are some DLL load problems)
_ in Cmake

• Release to Debug
• set path to boost lib
• changed /machine:X86 to /machine:X64 (3 rows)
• changed /Dwin32 flags to /Dwin64 (2 rows)
  _ changed active platform from win32 to x64 in VS (and this for all
  sub-projects)
  _ ALL_BUILD -> build UHD compiles and link fine
  _ INSTALL -> build, the bin folder is not copied to the target
  _ I copy uhd.dll manually, and uhd_find_devices.exe

running uhd_find_devices.exe gives :

C:\Program Files\UHD>uhd_find_devices.exe
Win32; Microsoft Visual C++ version 9.0; Boost_104900;
UHD_003.004.002-0-unknown

No UHD Devices Found

C:\Program Files\UHD>pause
Press any key to continue . . .

while when I'm trying with an older build, 32 bits, the device is found :

C:\Program Files (x86)\UHD_3_3_1_vc9_debug\bin>uhd_find_devices.exe
Win32; Microsoft Visual C++ version 9.0; Boost_104700;
UHD_003.003.001-unknown

-- UHD Device 0

Device Address:
type: usrp2
addr: 192.168.10.3
name:
serial:

C:\Program Files (x86)\UHD_3_3_1_vc9_debug\bin>pause
Press any key to continue . . .

My questions are :
_ why device is not found with 64 bit version ?
_ How can I avoid setting manually x64 for each sub-project in VS 2008 ?
_ Why 64 bit version still prints Win32 on the command line ? Should I just
ignore that ?
_ What is the patch applied really doing ?

Thanks and Regards
Bastien

Hi,

Save time and use either Fedora or Ubuntu < 30 min?
Two weeks installing...oh man...?

Patrik
----- Original Message -----
From: Simon HB9DRV
To: 'Bastien Auneau' ; usrp-users@lists.ettus.com
Sent: Thursday, June 07, 2012 19:20
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder is notcopied by INSTALL build, USRP not found

Hi,

Over the last two weeks I've been through the Windows 64-bit integration process. In my case I'm using the latest unstable Debug and Release builds.

I used VS2010

I built Boost from source

I have to use shared CTRL and MFC in the executable because UHD.dll can only be used this way

I am now able to use UHD.dll and ship to my software commercial customers without worrying about the USRP support issues. I'm able to get a reliable 20MHz bandwidth using complex floats from a WBX board with a 2.8GHz CPU (i7).

Simon Brown, HB9DRV
http://dit-dit-dit.com

You are standing at the end of a road before a small brick building. Around you is a forest.

A small stream flows out of the building and down a gully. The sunspot count is 285.

From: usrp-users-bounces@lists.ettus.com [mailto:usrp-users-bounces@lists.ettus.com] On Behalf Of Bastien Auneau
Sent: 07 June 2012 16:14
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Windows 7 64 bit build issues : bin folder is not copied by INSTALL build, USRP not found

Hi All

I am building UHD 3.4.2 from last stable release, under Windows 7 64bit, VS 2008, using boost 1.49.0 (compiled it myself)
To get UHD 64 bit debug, I've done :
_ applied patch described here : http://comments.gmane.org/gmane.comp.hardware.usrp.e100/3420
(without this patch, there are some DLL load problems)
_ in Cmake
- Release to Debug
- set path to boost lib
- changed /machine:X86 to /machine:X64 (3 rows)
- changed /Dwin32 flags to /Dwin64 (2 rows)
_ changed active platform from win32 to x64 in VS (and this for all sub-projects)
_ ALL_BUILD -> build UHD compiles and link fine
_ INSTALL -> build, the bin folder is not copied to the target
_ I copy uhd.dll manually, and uhd_find_devices.exe

running uhd_find_devices.exe gives :

C:\Program Files\UHD>uhd_find_devices.exe
Win32; Microsoft Visual C++ version 9.0; Boost_104900; UHD_003.004.002-0-unknown

No UHD Devices Found

C:\Program Files\UHD>pause
Press any key to continue . . .

while when I'm trying with an older build, 32 bits, the device is found :

C:\Program Files (x86)\UHD_3_3_1_vc9_debug\bin>uhd_find_devices.exe
Win32; Microsoft Visual C++ version 9.0; Boost_104700; UHD_003.003.001-unknown

-- UHD Device 0

Device Address:
type: usrp2
addr: 192.168.10.3
name:
serial:

C:\Program Files (x86)\UHD_3_3_1_vc9_debug\bin>pause
Press any key to continue . . .

My questions are :
_ why device is not found with 64 bit version ?
_ How can I avoid setting manually x64 for each sub-project in VS 2008 ?
_ Why 64 bit version still prints Win32 on the command line ? Should I just ignore that ?
_ What is the patch applied really doing ?

Thanks and Regards
Bastien

USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

No,

Integrating USRP support into my software to a standard where I'm prepared
to make it available for mission critical systems. Not a single commercial
customers uses or even wants to use Linux.

I do miss a proper interface specification such as is available with other
radios such as RFspace.

Simon Brown, HB9DRV
http://dit-dit-dit.com/ http://dit-dit-dit.com

You are standing at the end of a road before a small brick building. Around
you is a forest.

A small stream flows out of the building and down a gully. The sunspot count
is 285.

From: Patrik Tast [mailto:patrik@poes-weather.com]

Save time and use either Fedora or Ubuntu < 30 min?

Two weeks installing...oh man...?

Simon,

Building under Windows 7 is quite an effort but to do so with full 64-bit
support is an outstanding achievement (at least in my humble opinion and
based on my own failures). As it took you two weeks to "bring it all
together", could you please share any tricks and tips that you might have
discovered or developed along the way (and that perhaps are not documented
elsewhere). For example, which dependencies were needed and which in turn
were built from source (and with with special options).

Thanks in advance,

Stan

From: usrp-users-bounces@lists.ettus.com
[mailto:usrp-users-bounces@lists.ettus.com] On Behalf Of Simon HB9DRV
Sent: 07 June 2012 18:20
To: 'Bastien Auneau'; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder is
notcopied by INSTALL build, USRP not found

Hi,

Over the last two weeks I've been through the Windows 64-bit integration
process. In my case I'm using the latest unstable Debug and Release builds.

I used VS2010

I built Boost from source

I have to use shared CTRL and MFC in the executable because UHD.dll can only
be used this way

I am now able to use UHD.dll and ship to my software commercial customers
without worrying about the USRP support issues. I'm able to get a reliable
20MHz bandwidth using complex floats from a WBX board with a 2.8GHz CPU
(i7).

Simon Brown, HB9DRV
http://dit-dit-dit.com/ http://dit-dit-dit.com

You are standing at the end of a road before a small brick building. Around
you is a forest.

A small stream flows out of the building and down a gully. The sunspot count
is 285.

From: usrp-users-bounces@lists.ettus.com
[mailto:usrp-users-bounces@lists.ettus.com] On Behalf Of Bastien Auneau
Sent: 07 June 2012 16:14
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Windows 7 64 bit build issues : bin folder is not
copied by INSTALL build, USRP not found

Hi All

I am building UHD 3.4.2 from last stable release, under Windows 7 64bit, VS
2008, using boost 1.49.0 (compiled it myself)
To get UHD 64 bit debug, I've done :
_ applied patch described here :
http://comments.gmane.org/gmane.comp.hardware.usrp.e100/3420
(without this patch, there are some DLL load problems)
_ in Cmake

• Release to Debug
• set path to boost lib
• changed /machine:X86 to /machine:X64 (3 rows)
• changed /Dwin32 flags to /Dwin64 (2 rows)
  _ changed active platform from win32 to x64 in VS (and this for all
  sub-projects)
  _ ALL_BUILD -> build UHD compiles and link fine
  _ INSTALL -> build, the bin folder is not copied to the target
  _ I copy uhd.dll manually, and uhd_find_devices.exe

running uhd_find_devices.exe gives :

C:\Program Files\UHD>uhd_find_devices.exe
Win32; Microsoft Visual C++ version 9.0; Boost_104900;
UHD_003.004.002-0-unknown

No UHD Devices Found

C:\Program Files\UHD>pause
Press any key to continue . . .

while when I'm trying with an older build, 32 bits, the device is found :

C:\Program Files (x86)\UHD_3_3_1_vc9_debug\bin>uhd_find_devices.exe
Win32; Microsoft Visual C++ version 9.0; Boost_104700;
UHD_003.003.001-unknown

-- UHD Device 0

Device Address:
type: usrp2
addr: 192.168.10.3
name:
serial:

C:\Program Files (x86)\UHD_3_3_1_vc9_debug\bin>pause
Press any key to continue . . .

My questions are :
_ why device is not found with 64 bit version ?
_ How can I avoid setting manually x64 for each sub-project in VS 2008 ?
_ Why 64 bit version still prints Win32 on the command line ? Should I just
ignore that ?
_ What is the patch applied really doing ?

Thanks and Regards
Bastien

Hi,

Will do. BTW - two weeks included work on my own software. For a Windows
purist the UHD.dll architecture is 'unusual', the steps needed to use it in
a major project just aren't documented. In my case I have many DLLs (one per
manufacturer/radio model) with a common set of exported functions, these
DLLs are loaded dynamically. This caused some nice problems to be overcome.

What I'll do is update a blog on my dit-dit-dit.com website, but it's clear
that Windows support s weak when compared to the many other interface
libraries I use (CodeJock, Intel IPP, .). Ideally Ettus would provide
interface documentation so that a lean, clean and well-written interface can
be created. (If you browse the source you will find some unpleasant
eye-openers. As a developer of 30+ years I would reject the source.)

But - now that I have been through the hoops I'm prepared to release my code
for in-house testing, but am still unhappy with UHD.dll and the lack of
low-level documentation. Ettus does describe the hardware as test equipment,
with better documentation it could be used well in the real world.

I'll update now, will report back.

Simon Brown, HB9DRV
http://dit-dit-dit.com/ http://dit-dit-dit.com

You are standing at the end of a road before a small brick building. Around
you is a forest.

A small stream flows out of the building and down a gully. The sunspot count
is 285.

From: Stan Gamla [mailto:cystrin@hotmail.com]

Building under Windows 7 is quite an effort but to do so with full 64-bit
support is an outstanding achievement (at least in my humble opinion and
based on my own failures). As it took you two weeks to "bring it all
together", could you please share any tricks and tips that you might have
discovered or developed along the way (and that perhaps are not documented
elsewhere). For example, which dependencies were needed and which in turn
were built from source (and with with special options).

Hi Stan,

My notes are here:
http://dev.dit-dit-dit.com/Blog/tabid/88/post/ettus-research-notes/Default.a
spx

If you need help let me know. I think I have addressed all the issues you
will can come across.

Simon Brown, HB9DRV
http://dit-dit-dit.com/ http://dit-dit-dit.com

You are standing at the end of a road before a small brick building. Around
you is a forest.

A small stream flows out of the building and down a gully. The sunspot count
is 285.

From: Stan Gamla [mailto:cystrin@hotmail.com]

Building under Windows 7 is quite an effort but to do so with full 64-bit
support is an outstanding achievement (at least in my humble opinion and
based on my own failures). As it took you two weeks to "bring it all
together", could you please share any tricks and tips that you might have
discovered or developed along the way (and that perhaps are not documented
elsewhere). For example, which dependencies were needed and which in turn
were built from source (and with with special options).