Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Windows 7 64 bit build issues : bin folder is not copied
by INSTALL build, USRP not found (Simon HB9DRV)
2. Re: Windows 7 64 bit build issues : bin folder is not copied
by INSTALL build, USRP not found (Bastien Auneau)
3. N210 Orange Blinking Light Only (Alexander Olihovik)
4. Re: Config N210 with Microblaze (Ian Buckley)
5. Re: Windows 7 64 bit build issues : bin folder is not copied
by INSTALL build, USRP not found (Bastien Auneau)
6. problem with usrp_n2xx_net_burner_gui.py (Bastien Auneau)
7. Re: Windows 7 64 bit build issues : bin folder is notcopied
by INSTALL build, USRP not found (Patrik Tast)
8. Re: Windows 7 64 bit build issues : bin folder is notcopied
by INSTALL build, USRP not found (Bastien Auneau)
9. Re: API for N210 reset (Josh Blum)
10. Re: Windows 7 64 bit build issues : bin folder is notcopied
by INSTALL build, USRP not found (Simon HB9DRV)
11. Re: problem with usrp_n2xx_net_burner_gui.py (Josh Blum)
12. Re: Access Violation When Running UHD on Windows XP 32-bit
with VS 9 - 2008 (Josh Blum)
13. Re: Windows 7 64 bit build issues : bin folder is not copied
by INSTALL build, USRP not found (Josh Blum)
14. Re: Windows 7 64 bit build issues : bin folder is notcopied
by INSTALL build, USRP not found (Patrik Tast)
15. Tougher Case? (Simon HB9DRV)
16. Re: Windows 7 64 bit build issues : bin folder is notcopied
by INSTALL build, USRP not found (Bastien Auneau)
17. Re: API for N210 reset (Antonio Mancina)
18. problem with usrp_n2xx_net_burner_gui.py (Bastien Auneau)
19. Re: Windows 7 64 bit build issues : bin folder is not copied
by INSTALL build, USRP not found (Stefano Speretta)
----------------------------------------------------------------------
Message: 1
Date: Thu, 7 Jun 2012 18:20:03 +0200
From: "Simon HB9DRV" <[email protected]>
To: "'Bastien Auneau'" <[email protected]>, <[email protected]>
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder
is not copied by INSTALL build, USRP not found
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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: [email protected]
[mailto:[email protected]] On Behalf Of Bastien Auneau
Sent: 07 June 2012 16:14
To: [email protected]
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120607/5bb40b10/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 7 Jun 2012 18:25:35 +0200
From: Bastien Auneau <[email protected]>
To: Simon HB9DRV <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder
is not copied by INSTALL build, USRP not found
Message-ID:
<CA+avJoanm572B6jZiuWywcA8_VscjNnuPwApH5J2m3cPTUPh=a...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Hi Simon
Thanks for the answer
What do you mean by :
"I have to use shared CTRL and MFC in the executable because UHD.dll can
only be used this way" ?
Can you explain or point to on-line doc ?
Best Regards
Bastien
On 7 June 2012 18:20, Simon HB9DRV <[email protected]> wrote:
> 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:* [email protected] [mailto:
> [email protected]] *On Behalf Of *Bastien Auneau
> *Sent:* 07 June 2012 16:14
> *To:* [email protected]
> *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****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120607/de278897/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 7 Jun 2012 12:42:47 -0400
From: Alexander Olihovik <[email protected]>
To: [email protected]
Subject: [USRP-users] N210 Orange Blinking Light Only
Message-ID:
<CAFkrSAeLVFyvmhxiK+UXT0su1ZTikzR_O=6mkadzdjlj92q...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi everyone, I'm having some issues with the N210.
I plugged in the N210 while holding S2 to go into safe mode to put the
firmware on the device after unsuccessfully burning the image previously.
I was running usrp_n2xx_net_burner_gui.py
Firmware Image: usrp_n210_fw.bin
FPGA Image: usrp_n210_r4_fpga.bin
Everything burned successfully, and I attempted to restart the N210 at the
conclusion of the program.
However, now when I restart or plug in the USRP, no LEDs turn on. There is
only an orange light blinking on the Ethernet port.
I can ping 192.168.10.2, but uhd_find_devices can't find the USRP.
Does anyone have the solution or ideas to solve this problem?
Any information helps!
Best regards,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120607/204d452d/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 7 Jun 2012 09:54:30 -0700
From: Ian Buckley <[email protected]>
To: Huldi Michael <[email protected]>
Cc: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Config N210 with Microblaze
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Michael, I'm a little confused by what your actual question is? It seems your
having fundamental tactical problems loading a new FPGA image onto the N210,
but the question you pose is architectural: "Is it possible to program the fpga
with impact via JTAG? How could I insert the zpu firmware file in this case?"
I'm not going to address your problems with using the Xilinx Microblaze SDK,
that's a Xilinx proprietary flow and not something I, nor anyone at Ettus uses.
But I'll try to give you some architectural guidelines how to add a new
microprocessor to the N210:
First, yes it's entirely possible to use impact to program the FPGA, this is
how all new H/W is initially brought up. However note that unless you design
the H/W to have an attached FLASH RAM in a way supported by impact for JTAG
programming then you are only to directly configure the FPGA and that
configuration will be lost every power cycle/reset. The USRP SPI flash is not
programable via impact, so all non-volatile FPGA images and firmware images
have to be burned under firmware & FPGA control.
Now to boot an embedded microprocessor there are generally 2 different
approaches:
1) The boot vector (PC after reset) directly addresses a discrete FLASH RAM
that you can program externally (normally via JTAG)...this option doesn't exist
for unmodified N210 H/W.
2) The boot vector addresses an internal stable boot ROM (a pre-initialized
BRAM in a Xilinx) and the microcode in there performs a second stage boot,
getting more firmware from elsewhere (FLASH RAM, network etc). This is how the
stock N210 works with the ZPU and the attached SPI flash, which contains
multiple FPGA and firmware images. In this case the ZPU boot's with the bootrom
code in one BRAM, and uses this code to load the production firmware ware image
from SPI FLASH to the other at which point it does a quick FPGA logic trick,
swaps the MSB of the 2 BRAM's so that the boot vector now points to the other
BRAM and toggles the ZPU reset line to cause a new (ZPU not FPGA) boot.
Since you already have a working bootable and upgradable system in the stock
N210, I strongly suggest the following approach:
1) Add your second microprocessor (I suggest reusing the ZPU, firmware
libraries and tools..but you may have a compelling reason to learn and use
Xilinx microblaze SDK) to the existing FPGA build methodology and continue to
use the Ettus Makefile driven scripts to build and upload a new FPGA image via
the network.
2) Make the BRAM(s) that contain the firmware for your new microprocessor exist
also in the existing ZPU memory map. You can do this either by multiplexing
them or making use of the dual port nature of BRAM.
3) Write some extra firmware for the existing ZPU so that it handles the
download of your new microprocessors firmware from network to SPI flash and
from SPI flash to BRAM exploiting all the TCP/IP based updater code that
already exists. Boot your second microprocessor after and under the control of
the original ZPU.
This will be less work than you imagine since you will essentially be able to
re-use all Josh's existing firmware code and the H/W design idea's behind the
N210. You'll have a system quickly where you will not have to rebuild the FPGA
every time you change firmware.
Hope this helps,
-Ian
On Jun 7, 2012, at 5:53 AM, Huldi Michael wrote:
> Hello,
>
> I need help to get a simple microblaze configuration with bram-memory working
> with the USRP N210 release_003_004_001.
>
> I removed the tx chain and insert the microblaze in the top and connect 2 of
> the leds from the front to the microblaze gpio. Run a software with a
> blinking led function.
>
> I tried different ways to program the fpga without success:
>
> 1. add the elf-file from the microblaze to the ise-project and generate a
> .bin File with double click to "generate programming file" in ise, then
> download with net burner.
>
> 2. combine the bitstream with the elf file, which resides in the bram in SDK
> with "Programm FPGA" to a .bit file, then convert the generated file
> download.bit to a .bin file with "promgen -u 0x0 download.bit -p bin -w " and
> try to download with net burner. But the net burner says "Invalid FPGA image
> file".
>
> 3. Download with Platform Cable and with SDK, JTAG connected to the FPGA. But
> here it doesn't load the new configuration, since the leds I disconnect still
> light up in startup.
>
> I also changed the StartUpClk in the bitgen.ut from JTAGCLK to CCLK.
>
> Someone have an idea, how to make my configuration working? Is it possible to
> program the fpga with impact via JTAG? How could I insert the zpu firmware
> file in this case?
>
> Thanks for your help!
> Huldi
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120607/88a82854/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 7 Jun 2012 18:59:50 +0200
From: Bastien Auneau <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder
is not copied by INSTALL build, USRP not found
Message-ID:
<ca+avjob6wi3pxjcbe_mzxqdyv4qsxmmbyt7w6qqb8_b4c2x...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi All
I found some answers, and would like to share it, in case anyone is
interested
I answer the list of question I've asked in previous email :
_ why device is not found with 64 bit version ?
--> this works after updating FW and FPGA (I think that wrong version was
loaded before, 210 instead of 200)
_ How can I avoid setting manually x64 for each sub-project in VS 2008 ?
--> Still no answer...
_ Why 64 bit version still prints Win32 on the command line ? Should I just
ignore that ?
-->it is the same when downloading the Win64 compiled version from Ettus
website. So I guess it can just be ignored
_ What is the patch applied really doing ?
--> no answer on that...
On 7 June 2012 16:13, Bastien Auneau <[email protected]> wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120607/b3b2a3f1/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 7 Jun 2012 19:04:31 +0200
From: Bastien Auneau <[email protected]>
To: [email protected]
Subject: [USRP-users] problem with usrp_n2xx_net_burner_gui.py
Message-ID:
<CA+avJoantzsdVbASZDfJ6m=1_sjsgehjklrq7zr2-nyzunz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi All
Everytime I use the Python usrp_n2xx_net_burner_gui.py script I run into
some error :
C:\Program
Files\UHD_3_4_2_bin_debug_win64\share\uhd\utils>usrp_n2xx_net_burner_
gui.py
192.168.10.1
????
Traceback (most recent call last):
File "C:\Program
Files\UHD_3_4_2_bin_debug_win64\share\uhd\utils\usrp_n2xx_net
_burner_gui.py", line 231, in <module>
USRPN2XXNetBurnerApp(root, addr=options.addr, fw=options.fw,
fpga=options.fp
ga).pack()
File "C:\Program
Files\UHD_3_4_2_bin_debug_win64\share\uhd\utils\usrp_n2xx_net
_burner_gui.py", line 158, in __init__
self._net_dev_entry = DeviceEntryWidget(self, text=addr)
File "C:\Program
Files\UHD_3_4_2_bin_debug_win64\share\uhd\utils\usrp_n2xx_net
_burner_gui.py", line 100, in __init__
self._reload_cb()
File "C:\Program
Files\UHD_3_4_2_bin_debug_win64\share\uhd\utils\usrp_n2xx_net
_burner_gui.py", line 113, in _reload_cb
for hint in usrp_n2xx_net_burner.enumerate_devices():
File "C:\Program
Files\UHD_3_4_2_bin_debug_win64\share\uhd\utils\usrp_n2xx_net
_burner.py", line 215, in enumerate_devices
for bcast_addr in get_interfaces():
File "C:\Program
Files\UHD_3_4_2_bin_debug_win64\share\uhd\utils\usrp_n2xx_net
_burner.py", line 201, in win_get_interfaces
ipAddr = adNode.ipAddress.decode()
UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0:
ordinal
not in range(128)
C:\Program Files\UHD_3_4_2_bin_debug_win64\share\uhd\utils>pause
Press any key to continue . . .
____________________________
The
"192.168.10.1
????"
Is a result of adding "print adNode.ipAddress" at line 200 of
usrp_n2xx_net_burner.py
The work around I found is to do that :
"#ipAddr = adNode.ipAddress.decode()
ipAddr = "192.168.10.1".decode()
"
Meaning that I hardcode the local IP of my PC
I tried to get ride of these last "????" without success
Does anyone knows how to fix that permanently (this has been around since I
work with UHD)
Best Regards
Bastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120607/6830677e/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 7 Jun 2012 20:31:27 +0300
From: "Patrik Tast" <[email protected]>
To: "Simon HB9DRV" <[email protected]>, "'Bastien Auneau'"
<[email protected]>, <[email protected]>
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder
is notcopied by INSTALL build, USRP not found
Message-ID: <9023C64FA64245788BAB5AA04935677B@hp>
Content-Type: text/plain; charset="iso-8859-1"
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' ; [email protected]
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: [email protected]
[mailto:[email protected]] On Behalf Of Bastien Auneau
Sent: 07 June 2012 16:14
To: [email protected]
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
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120607/03f290ce/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 7 Jun 2012 19:36:00 +0200
From: Bastien Auneau <[email protected]>
To: Patrik Tast <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder
is notcopied by INSTALL build, USRP not found
Message-ID:
<CA+avJoYz7MmULmLLy+o6yJ_pL4=FER49GF+qYmMY=jyl-vd...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Hi Patrik
No problem with Ubuntu. I definitely prefer it to Windows. My company has
seen an increase of linux machine since I'm employed there.
But sometimes, in the real world, there isn't always choice of platform
(dependencies, history, customer request, etc...)
Best Regards
Bastien
On 7 June 2012 19:31, Patrik Tast <[email protected]> wrote:
> **
> Hi,
>
> Save time and use either Fedora or Ubuntu < 30 min?
> Two weeks installing...oh man...?
>
> Patrik
>
> ----- Original Message -----
> *From:* Simon HB9DRV <[email protected]>
> *To:* 'Bastien Auneau' <[email protected]> ; [email protected]
> *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:* [email protected] [mailto:
> [email protected]] *On Behalf Of *Bastien Auneau
> *Sent:* 07 June 2012 16:14
> *To:* [email protected]
> *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
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120607/0b6a0bde/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 07 Jun 2012 10:40:03 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] API for N210 reset
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/07/2012 08:37 AM, Antonio Mancina wrote:
> Hi all,
>
> I've just come to know that it is possible to reset the device
> using the usrp_n2xx_net_burner.py util with the --reset switch.
>
> I was wondering whether such a possibility exists using the C++ API
> as well, because I was unable to find anything related to it
> in the documentation.
>
There isnt an API to reset the device. The contructor for the device
should be re-initialing everything, every time, including clearing fifos
and such. Are you seeing an issue, something is in a bad state?
-josh
> Thanks everyone,
> Antonio
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 10
Date: Thu, 7 Jun 2012 19:40:40 +0200
From: "Simon HB9DRV" <[email protected]>
To: "'Patrik Tast'" <[email protected]>, "'Bastien Auneau'"
<[email protected]>, <[email protected]>
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder
is notcopied by INSTALL build, USRP not found
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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:[email protected]]
Save time and use either Fedora or Ubuntu < 30 min?
Two weeks installing...oh man...?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120607/5f1c433f/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 07 Jun 2012 10:49:55 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] problem with usrp_n2xx_net_burner_gui.py
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
> File "C:\Program
> Files\UHD_3_4_2_bin_debug_win64\share\uhd\utils\usrp_n2xx_net
> _burner.py", line 201, in win_get_interfaces
> ipAddr = adNode.ipAddress.decode()
> UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0:
> ordinal
> not in range(128)
>
Well, this is a new one. I wouldnt expect the ipaddress to contain non
ascii characters.
Its also possible to adNode.ipMask.decode('ascii', errors='ignore'),
which unfortunately is newer versions of python only.
Looks like we need our own decode to ascii + ignore for portability...
-josh
------------------------------
Message: 12
Date: Thu, 07 Jun 2012 11:07:25 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Access Violation When Running UHD on Windows
XP 32-bit with VS 9 - 2008
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/19/2012 03:34 AM, Bastien Auneau wrote:
> Hi
>
> I had the same problem recently, and assumed I just had something wrong
> in my toolchain
> I have been using UHD 64 bit under Windows 7 the past half year,
> checking out the last code, compiling an using it several times. I use
> Visual Studio 2008. I compiled boost lib from source
>
> Using the last maint branch (3.4.1) I also have access violation anytime
> UHD code is called
> I attach a screenshot of depedency walker to this email
> In case the attach file doesn't make it through, it complains for :
> _ missing GPSVC.dll IESHIMS.dll MSVCR90D.dll
> _ also compains about almost all other DLL because they are x86 (while I
> built UHD 64bit)
>
> Hope this help
> Best Regards
> Bastien
>
>
To give this some resolution. This is apparently a MSVC 2008 bug that is
exposed by boost 1.49. At least that is at least what the boost guys are
saying: https://svn.boost.org/trac/boost/ticket/6638
The best solution is probably to not use the combination of MSVC2008 and
boost 1.49
-josh
------------------------------
Message: 13
Date: Thu, 07 Jun 2012 11:11:17 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder
is not copied by INSTALL build, USRP not found
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/07/2012 07:13 AM, Bastien Auneau wrote:
> 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)
There is a bug here:
https://svn.boost.org/trac/boost/ticket/6638
> _ 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
>
You should tell CMake configure to use the MSVC 64 bit compiler. You
shouldnt need to change or set any flags. It will just work (tm)
You can simply open the MSVC x64 terminal and run:
DevEnv uhd.sln /build Debug /project ALL_BUILD
-josh
------------------------------
Message: 14
Date: Thu, 7 Jun 2012 21:29:52 +0300
From: "Patrik Tast" <[email protected]>
To: "Simon HB9DRV" <[email protected]>, "'Bastien Auneau'"
<[email protected]>, <[email protected]>
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder
is notcopied by INSTALL build, USRP not found
Message-ID: <20C91AFD0E2244B291B243F5BB4CEAD7@hp>
Content-Type: text/plain; charset="iso-8859-1"
Hi Simon,
>to a standard where I'm prepared to make it available for mission critical
>systems
...why did NASA dev team abandon MS and switch to linux, 2008? I do hope that
your systems are not that critical...
>Not a single commercial customers uses or even wants to use Linux.
most dedicated are using linux...novices are using MS, sure it works...
>I do miss a proper interface specification such as is available with other
>radios such as RFspace.
I don't think other radios see RF better, perhaps 1 - 3dB diff
Patrik
----- Original Message -----
From: Simon HB9DRV
To: 'Patrik Tast' ; 'Bastien Auneau' ; [email protected]
Sent: Thursday, June 07, 2012 20:40
Subject: RE: [USRP-users] Windows 7 64 bit build issues : bin folder is
notcopied by INSTALL build, USRP not found
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
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:[email protected]]
Save time and use either Fedora or Ubuntu < 30 min?
Two weeks installing...oh man...?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120607/a1b374cb/attachment-0001.html>
------------------------------
Message: 15
Date: Thu, 7 Jun 2012 20:30:56 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Tougher Case?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Has anyone used / created / designed / found a case for a N210 which would
be close to mil spec?
Similarly a case which is suitable for a high humidity environment?
Simon Brown, HB9DRV
http://dit-dit-dit.com
Not sent from an iPhone: I don't have one and I don't want one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120607/3406f0e5/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 7 Jun 2012 20:34:33 +0200
From: Bastien Auneau <[email protected]>
To: Patrik Tast <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder
is notcopied by INSTALL build, USRP not found
Message-ID:
<ca+avjoadj1k0v5zgrmsszplnw+g9ysdt3_yzb5ib3f6amdj...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Hi guys
Please discuss about how cool you think linux is in a new thread...
Sorry for that but I'd like to keep the focus on thread topic :
_ how to build UHD 64 bit without having to select 64 for each sub-project
in VS2008 Configuration manager ?
_ why bin folder is not copied along with the other folders when building
INSTALL ?
_ what is the fixed
http://comments.gmane.org/gmane.comp.hardware.usrp.e100/3420 really doing ?
But I enjoy your enthusiasm for the discussion ;-)
Best Regards
Bastien
On 7 June 2012 20:29, Patrik Tast <[email protected]> wrote:
> **
> Hi Simon,
>
> >to a standard where I?m prepared to make it available for mission
> critical systems
> ...why did NASA dev team abandon MS and switch to linux, 2008? I do hope
> that your systems are not that critical...
> >Not a single commercial customers uses or even wants to use Linux.
> most dedicated are using linux...novices are using MS, sure it works...
>
> >I do miss a proper interface specification such as is available with
> other radios such as RFspace.****
> I don't think other radios see RF better, perhaps 1 - 3dB diff
>
> Patrik
>
> ----- Original Message -----
> *From:* Simon HB9DRV <[email protected]>
> *To:* 'Patrik Tast' <[email protected]> ; 'Bastien
> Auneau'<[email protected]>;
> [email protected]
> *Sent:* Thursday, June 07, 2012 20:40
> *Subject:* RE: [USRP-users] Windows 7 64 bit build issues : bin folder is
> notcopied by INSTALL build, USRP not found
>
> 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****
>
> ** **
>
> 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:[email protected]] ****
>
> ****
>
> Save time and use either Fedora or Ubuntu < 30 min?****
>
> Two weeks installing...oh man...? ****
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120607/7974dc1e/attachment-0001.html>
------------------------------
Message: 17
Date: Fri, 08 Jun 2012 10:26:58 +0200
From: Antonio Mancina <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] API for N210 reset
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi Josh,
> There isnt an API to reset the device. The contructor for the device
> should be re-initialing everything, every time, including clearing fifos
> and such. Are you seeing an issue, something is in a bad state?
actually this is not something you can easily reproduce. Sometimes, it
may happen that our N210s start behaving badly and we get corrupted
signals which prevent our modulation/demodulation chain from properly
working.
We still use UHD 3.1.2 so maybe this is not an issue any more.
Anyway, this seldom occurs, but when it's the case the only solution is
to reboot or reset the device. I think we will call python code from
our C++ framework in order to issue a device reset immediately before
starting our demodulation service.
Thanks,
Antonio
------------------------------
Message: 18
Date: Fri, 8 Jun 2012 09:46:03 +0000
From: Bastien Auneau <[email protected]>
To: [email protected], [email protected]
Subject: [USRP-users] problem with usrp_n2xx_net_burner_gui.py
Message-ID:
<ca+avjoyjqrbb-ncfqpz9jemc2shtlg6whv3y6fypffjon26...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Josh
It seems that the non ASCII characters are not part of my IP adresse
(192.168.10.1), but is rather another Ethernet adapter detected by the
python script
I attached a file with the proposed change at line 203
I'v just added an
except UnicodeDecodeError: ipAddr = None
but instead of pass, I set the ipAddr to None
If it is not set to None, the USRP device is detected twice (the previous
successful decode() value is re-used). As suggested in the code, the pass
of
except AttributeError: pass
maybe should be changed to
except AttributeError: ipAddr = None
This is probably worth merging in the main branch, I'm probably not the
only person with this issue
The 2 PC I had this issues with are DELL (optiplex 780 and XPS) running
Windows 7
Best Regards
Bastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120608/f38ea94e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usrp_n2xx_net_burner.py
Type: application/octet-stream
Size: 22606 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120608/f38ea94e/attachment-0001.py>
------------------------------
Message: 19
Date: Fri, 08 Jun 2012 17:31:05 +0200
From: Stefano Speretta <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Windows 7 64 bit build issues : bin folder
is not copied by INSTALL build, USRP not found
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> _ Why 64 bit version still prints Win32 on the command line ? Should I
> just ignore that ?
> -->it is the same when downloading the Win64 compiled version from
> Ettus website. So I guess it can just be ignored
The Windows platform in Boost is called "win32" but there is no link to
a 32/64 bit architecture, it's just a static definition...
Check boost source code here:
http://www.boost.org/doc/libs/1_49_0/boost/config/select_platform_config.hpp
http://www.boost.org/doc/libs/1_49_0/boost/config/platform/win32.hpp
Stefano
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 22, Issue 8
*****************************************
