nuand / bladerf Goto Github PK
View Code? Open in Web Editor NEWbladeRF USB 3.0 Superspeed Software Defined Radio Source Code
Home Page: http://nuand.com
License: Other
bladeRF USB 3.0 Superspeed Software Defined Radio Source Code
Home Page: http://nuand.com
License: Other
A number of the print arguments remain stubs (e.g., lmsregs).
Let's use this thread to aggregate a list of unimplemented items and either get them implemented or remove them for the time being.
Please submit patches against the dev-libusb_support branch, as this is further along and will soon be getting merged back into mainline.
bladeRF/host/build$ make
Scanning dependencies of target libbladerf_shared
[ 4%] Building C object libraries/libbladeRF/CMakeFiles/libbladerf_shared.dir/src/backend.c.o
[ 8%] Building C object libraries/libbladeRF/CMakeFiles/libbladerf_shared.dir/src/bladerf.c.o
[ 12%] Building C object libraries/libbladeRF/CMakeFiles/libbladerf_shared.dir/src/bladerf_priv.c.o
[ 16%] Building C object libraries/libbladeRF/CMakeFiles/libbladerf_shared.dir/src/device_identifier.c.o
[ 20%] Building C object libraries/libbladeRF/CMakeFiles/libbladerf_shared.dir/src/file_ops.c.o
[ 25%] Building C object libraries/libbladeRF/CMakeFiles/libbladerf_shared.dir/src/lms.c.o
[ 29%] Building C object libraries/libbladeRF/CMakeFiles/libbladerf_shared.dir/src/si5338.c.o
[ 33%] Building C object libraries/libbladeRF/CMakeFiles/libbladerf_shared.dir/__/__/common/src/conversions.c.o
[ 37%] Building C object libraries/libbladeRF/CMakeFiles/libbladerf_shared.dir/src/backend/libusb.c.o
bladeRF/host/libraries/libbladeRF/src/backend/libusb.c: In function ‘erase_flash’:
bladeRF/host/libraries/libbladeRF/src/backend/libusb.c:436:9: warning: variable ‘sector_to_erase’ set but not used [-Wunused-but-set-variable]
Linking C shared library libbladeRF.so
[ 37%] Built target libbladerf_shared
Scanning dependencies of target libbladeRF_test_async
[ 41%] Building C object libraries/libbladeRF/tests/test_async/CMakeFiles/libbladeRF_test_async.dir/main.c.o
Linking C executable libbladeRF_test_async
[ 41%] Built target libbladeRF_test_async
Scanning dependencies of target bladeRF-cli
[ 45%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/main.c.o
[ 50%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/common.c.o
[ 54%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/cmd/cmd.c.o
[ 58%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/cmd/load.c.o
[ 62%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/cmd/open.c.o
[ 66%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/cmd/peek.c.o
[ 70%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/cmd/peekpoke.c.o
[ 75%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/cmd/poke.c.o
[ 79%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/cmd/printset.c.o
[ 83%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/cmd/probe.c.o
[ 87%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/cmd/rxtx.c.o
[ 91%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/cmd/version.c.o
[ 95%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/__/__/common/src/conversions.c.o
[100%] Building C object utilities/bladeRF-cli/CMakeFiles/bladeRF-cli.dir/src/interactive/interactive.c.o
Linking C executable bladeRF-cli
[100%] Built target bladeRF-cli
bladeRF/host/build$ sudo make install
[ 37%] Built target libbladerf_shared
[ 41%] Built target libbladeRF_test_async
[100%] Built target bladeRF-cli
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/local/lib/pkgconfig/libbladeRF.pc
-- Installing: /usr/local/lib/libbladeRF.so.0
-- Installing: /usr/local/lib/libbladeRF.so
-- Installing: /usr/local/include/libbladeRF.h
-- Installing: /etc/udev/rules.d/88-nuand.rules
-- Installing: /usr/local/bin/bladeRF-cli
-- Removed runtime path from "/usr/local/bin/bladeRF-cli"
bladeRF/host/build$ sudo make uninstall
Scanning dependencies of target uninstall
CMake Warning (dev) at cmake_uninstall.cmake:9 (list):
Policy CMP0007 is not set: list command no longer ignores empty elements.
Run "cmake --help-policy CMP0007" for policy details. Use the cmake_policy
command to set the policy and suppress this warning. List has value =
[/usr/local/lib/pkgconfig/libbladeRF.pc;/usr/local/lib/libbladeRF.so.0;/usr/local/lib/libbladeRF.so;/usr/local/include/libbladeRF.h;/etc/udev/rules.d/88-nuand.rules;/usr/local/bin/bladeRF-cli;].
This warning is for project developers. Use -Wno-dev to suppress it.
-- Uninstalling "/usr/local/bin/bladeRF-cli"
-- Uninstalling "/etc/udev/rules.d/88-nuand.rules"
-- Uninstalling "/usr/local/include/libbladeRF.h"
-- Uninstalling "/usr/local/lib/libbladeRF.so"
-- Uninstalling "/usr/local/lib/libbladeRF.so.0"
-- Uninstalling "/usr/local/lib/pkgconfig/libbladeRF.pc"
Built target uninstall
See the swap when comparing the results of bladeRF-cli's "probe" command to lsusb.
After programming the FPGA and setting the GPIO bits to 0x57, using the CLI to do:
peek lms 0 0x80
The end of the register list will say:
Error: An unexpected error occurred
This error corresponds to an unchecked else statement in the kernel which indicates the device write has timed out.
This code from the CLI should be integrated into an API call, and the CLI adjusted to use this:
int set_sampling(struct cli_state *state, int argc, char **argv)
{
/* Usage: set sampling [internal|external] */
int rv = CMD_RET_OK;
uint8_t val = 0;
if( argc != 3 ) {
rv = CMD_RET_NARGS ;
} else {
if( strcasecmp( "internal", argv[2] ) == 0 ) {
/* Disconnect the ADC input from the outside world */
bladerf_lms_read( state->dev, 0x09, &val );
val &= ~(1<<7) ;
bladerf_lms_write( state->dev, 0x09, val );
/* Turn on RXVGA2 */
bladerf_lms_read( state->dev, 0x64, &val );
val |= (1<<1) ;
bladerf_lms_write( state->dev, 0x64, val );
} else if( strcasecmp( "external", argv[2] ) == 0 ) {
/* Turn off RXVGA2 */
bladerf_lms_read( state->dev, 0x64, &val );
val &= ~(1<<1) ;
bladerf_lms_write( state->dev, 0x64, val );
/* Connect the external ADC pins to the internal ADC input */
bladerf_lms_read( state->dev, 0x09, &val );
val |= (1<<7) ;
bladerf_lms_write( state->dev, 0x09, val );
} else {
cli_err(state, argv[0], "Invalid sampling mode (%s)", argv[2] );
}
}
return rv;
}
The following items will need to be fixed/replaced for portability:
In routines like bladerf_enable_module() we need to ensure there's a default case in the switch statement that returns BLADERF_ERR_INVAL. This would help users catch things like uninitialized values being passed to these routines.
Basically I/Q are registred but the IQSel signal is used as if they were not and so I/Q get mixed across sample.
rf_rx_fifo_w <= not lms_rx_iq_select;
Solution would be to either to register lms_rx_iq_select, or simply not to invert it since that signal is just 0/1/0/1/...
Software workaround is to inverse polarity of IQSel in LMS 0x5a ...
TODO - check state->curr_device in printset.c and return a less cryptic error.
In Linux (haven't tested on other OSs), if libncurses is not installed, the build process will fail as the library is unavailable to link against. First, I'm not sure that this library is necessary to begin with on Linux, as I was able to build libtecla support previously without it. Second, if it is necessary, it should be detected during the cmake process rather than during the make process.
UPDATE: I verified that removing the ncurses library dependency from the CMakeLists still allows the CLI to build fine without libncurses present. Thus, I don't believe this dependency is required for linux.
After setting a samplerate of 2MHz, the clock going to the LMS is 4MHz (correct) but the total number of samples delivered to the host system is only 1Msps. Samples appear to be disappearing between the FPGA and FX3 when in HS mode at a rate of very close to 1/2 the samples being dropped.
The c16_sample_fixup routine should be reviewed for proper endian conversion. Samples coming from the FX3 (little endian) need to be converted to the file format endianness, NOT the host endianness.
A critical eye reviewing potential endianess issues would be appreciated, however.
This is sorely out of date.
I'd volunteer to update it if someone could let me know what content should be in there.
I know there had been some discussion about developing a docs/ full of multimarkdown-based documentation. So perhaps the top-level README should just provide info on where in the tree to find everything, point the website, git repo, issue tracker, forum, site, etc?
The device doesn't show up in /dev when running kernel 3.2 (Comes with ubuntu 12.0.4 LTS)
Work around is simple use 3.5+
If using Ubuntu 12.04 LTS http://askubuntu.com/questions/257617/how-can-i-upgrade-the-ubuntu-12-04-2-kernel-to-3-5-0-23
Running "make INTERACTIVE=n" gives me this output:
mkdir -p bin
make -C src/cli \
BIN_DIR="/home/cyrozap/bladeRF/linux/apps/bin" CFLAGS="-Wall -Wextra -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -O2 -DNDEBUG" LDFLAGS="-lbladeRF " INTERACTIVE="n"
make[1]: Entering directory `/home/cyrozap/bladeRF/linux/apps/src/cli'
cc common.c -Wall -Wextra -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -O2 -DNDEBUG -Icmd -Iinteractive -I. -pthread -c -o common.o
cc main.c -Wall -Wextra -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -O2 -DNDEBUG -Icmd -Iinteractive -I. -pthread -c -o main.o
main.c:318:54: error: macro "interactive" passed 2 arguments, but takes just 1
main.c: In function ‘main’:
main.c:318: error: ‘interactive’ undeclared (first use in this function)
main.c:318: error: (Each undeclared identifier is reported only once
main.c:318: error: for each function it appears in.)
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/home/cyrozap/bladeRF/linux/apps/src/cli'
make: *** [bin/cli] Error 2
When I run the osmosdr-siggen program it appears to properly configure the FPGA and lime chip for the Carrier requested in the GUI. The TX Gain adjusts seems to be working as well. But I can't seem to get samples into the modulator.
my /dev/bladerf0 file is mode 666
running osmosdr-siggen
user@host $ ./osmosdr-siggen
In the console I get:
Failed to write samples: provided parameters where out of allowable range.
When I change the carrier frequency, the bladeRF responses. On my spectrum analyzer I can see the TX carrier (LO leakage) move.
But can't get any samples though...
Stopping the osmosdr-siggen causes the LO on the lime chip to disappear. Chip deactivate, as expected result.
Sometimes after running it and start osmosdr-siggen up again.
I get the dreaded "Bladerf_enable_module has returned with -6"
Which I think means the board got stuck..
Doesn't go away until I power cycle the bladeRF.
I am using the lastest bladeRF GIT (as of 8/2/2013 00:53:00 UTC ) and the latest osmosdr git head.
Running ubuntu-13.04 linux-3.8 kernel.
This appears to return bytes, rather than # of IQ pairs sent, which contradicts the interface defined in libbladeRF.h.
For, example I'd expect the following to return 1024. However, it will return 4096:
ssize_t len = bladerf_read_c16(this->dev, buf, 1024);
Should the return value or the interface change? FWIW, I vote this returning 1024, so the units of the parameters and the return value are consistent.
On a similar note, it might be worth noting in the doxygen comments that the _c16 function deal with a pair of 16-bit IQ values, not 16-bits total... I suppose it might be clear, but that has potential to snag someone.
The pointer increments for buffers is wrong
i = read(dev->fd, samples + bytes_read, bytes_total - bytes_read);
I think it should be something like.
i = read(dev->fd, samples + bytes_read/sizeof(int16_t), bytes_total - bytes_read);
The initial frequency set tunes both rx and tx. Subsequent set frequency commands do not tune the tx, the tx is stuck on whatever the initial frequency set was. tx is tunable in gnuradio on linux, this bug seems to be limited to windows.
Provide the ability to call scripts from the console (or from within other scripts) -- this will allow module little scripts to be created and reused.
Currently in the works, will finish up and commit after some higher priority items.
TO DO - correct the implementation of host/cmake/modules/Version.cmake to only append -dirty
when the git repo is not in a clean state.
The data of interest is likely the calibration data sector, for backup purposes.
However, being able to read back arbitrary sections of flash might come in useful down the line.
"With great powers comes great responsibility". Running in kernel space is a bit like that :)
For example this snippet : (there is actually the same kind of safety issue in various forms at various places)
if (copy_from_user(&brf_fw, data, sizeof(struct bladeRF_firmware))) {
return -EFAULT;
}
fw_buf = kzalloc(256, GFP_KERNEL);
if (!fw_buf)
return -EINVAL;
memset(fw_buf, 0xff, 256);
if (copy_from_user(fw_buf, brf_fw.ptr, brf_fw.len)) {
retval = -EFAULT;
kfree(fw_buf);
break;
}
The brf_fw.len can't be trusted ... it comes from userspace and you use it for a memcpy into a kernel buffer of fixed space. So userspace can overrun it and do bad things.
Everything coming from userspace must be checked and not trusted.
You should also not assume anything about the device, someone could impersonate the bladeRF IDs and trigger bad driver behavior to compromise the machine. For eg:
sz = 0;
if (dev->udev->speed == USB_SPEED_HIGH) {
sz = 64;
} else if (dev->udev->speed == USB_SPEED_SUPER) {
sz = 256;
}
What about the other speed ? Like if the device pretended to be low speed, sz=0 and the code doesn't return -EINVAL or -EFAULT, it just continues with a bad size.
When built for release mode, the FX3 firmware does not ever produce samples coming back to the host. The kernel driver fails to send a control message with a return code of -110 followed by 2 more with a return code of -71.
Compiling the FX3 firmware for debug with DEBUG=yes creates a working firmware.
There are a number of warnings that look like they might be the cause of some issues.
lms_lpf_enable doesn't change the enable bit unless you're changing bandwidth, when calling it after lms_lpf_disable you have to specify something other than 28Mhz for the call to work.
proposed fix
// When enabling an LPF, we must select both the module and the filter bandwidth
void lms_lpf_enable( struct bladerf *dev, lms_module_t mod, lms_bw_t bw )
{
uint8_t reg = (mod == RX) ? 0x54 : 0x34 ;
uint8_t data ;
// Check to see which bandwidth we have selected
lms_spi_read( dev, reg, &data ) ;
data |= (1<<1) ;
if( (lms_bw_t)(data&0x3c>>2) != bw )
{
data &= ~0x3c ;
data |= (bw<<2) ;
}
lms_spi_write( dev, reg, data ) ;
// Check to see if we are bypassed
lms_spi_read( dev, reg+1, &data ) ;
if( data&(1<<6) )
{
data &= ~(1<<6) ;
lms_spi_write( dev, reg+1, data ) ;
}
return ;
}
The FPGA design contains a asynchronous reset, which is fine. However the reset release (ie falling edge) is also asynchronous. This may result in different parts of the design leaving reset. A reset controller should created to provide a synchronous reset release.
Fresh load of FPGA, open bladerf-cli -i, trying to tx a test csv file full of 2047, 0. No signal goes out (viewing from an rtlsdr on a laptop to verify).
Open gnuradio, run a test tx script, transmits strong with the exact same settings CLI had. Close out of gnuradio, boot back into bladerf-cli, tx config file=/tmp/test.csv format=csv repeat=0 and tx start and big spike on the spectrum as expected.
Exit out, reload fpga, go back into CLI and can't tx no matter what settings. Run the gnuradio tx test script and go back to CLI and CLI can tx just fine. Interesting to note, I can tx start tx stop as many times as I want after running the gnuradio script. As soon as I set frequency to something else then tx start, CLI stops allowing me to transmit no matter what.
What does gr-osmosdr do to init bladerf? It's configuring something to allow the tx to work.
115KLE FPGA is reported as a 40KLE. This is due to a typo in bladerf_priv.c
Find the patch here-below
diff --git a/host/libraries/libbladeRF/src/bladerf_priv.c b/host/libraries/libbladeRF/src/bladerf_priv.c
index 727b870..f371120 100644
--- a/host/libraries/libbladeRF/src/bladerf_priv.c
+++ b/host/libraries/libbladeRF/src/bladerf_priv.c
@@ -295,7 +295,7 @@ int bladerf_get_and_cache_fpga_size(struct bladerf *device)
if (!strcmp("40", tmp)) {
device->fpga_size = BLADERF_FPGA_40KLE;
} else if(!strcmp("115", tmp)) {
- device->fpga_size = BLADERF_FPGA_40KLE;
+ device->fpga_size = BLADERF_FPGA_115KLE;
} else {
device->fpga_size = BLADERF_FPGA_UNKNOWN;
}
TODO item
Intended to allow a user to execute a single command and exit.
For rx/tx commands this will require waiting until the command completes. (This is a similar requirement for scripting support, when 'rx start' is at the end of a script)
Right now, there's a few items (e.g., struct bladeRF_firmware) that are exchanged without serialization/deserialization.
Fortunately, all these are nicely aligned and not padded structures. However, this will yield nasty results if and when changes are made to the relevant structures.
See http://pastebin.com/AsBhyky3
Not sure why/how it happened, but it should just not be possible. Looks like missing locking somewhere / bad concurrency / race ...
Result was that USB became unusable and the process accessing the bladrf was left unkillable, using 100% of CPU. So just had to reboot ...
Hi,
I have 2 boards connected to my system, 1 being driven by osmocom_fft and the other by siggen. Seconds into the experience my system crashes and when I recover my syslog contains the trace below.
The driver I am running was all built yesterday.
Regards
Paul
Aug 21 17:43:47 Z820 kernel: [33464.603045] ------------[ cut here ]------------
Aug 21 17:43:47 Z820 kernel: [33464.603061] WARNING: at /build/buildd/linux-3.8.0/kernel/watchdog.c:246 watchdog_overflow_callback+0x9c/0xd0()
Aug 21 17:43:47 Z820 kernel: [33464.603065] Hardware name: HP Z820 Workstation
Aug 21 17:43:47 Z820 kernel: [33464.603067] Watchdog detected hard LOCKUP on cpu 4
Aug 21 17:43:47 Z820 kernel: [33464.603069] Modules linked in: nfnetlink_log(F) nfnetlink(F) r8712u(C) binfmt_misc(F) nls_utf8 hfsplus snd_hda_codec_hdmi coretemp kvm ghash_clmulni_intel(F) aesni_intel(F) aes_x86_64(F) xts(F) lrw(F) gf128mul(F) ablk_helper(F) cryptd(F) gpio_ich hp_wmi sparse_keymap parport_pc(F) microcode(F) ppdev(F) psmouse(F) serio_raw(F) sb_edac edac_core bnep rfcomm bluetooth snd_hda_codec_realtek nvidia(POF) lpc_ich snd_seq_midi(F) snd_seq_midi_event(F) snd_rawmidi(F) snd_hda_intel snd_hda_codec snd_hwdep(F) snd_pcm(F) mei snd_page_alloc(F) snd_seq(F) snd_seq_device(F) snd_timer(F) snd(F) soundcore(F) wmi mac_hid nls_iso8859_1(F) bladeRF(OF) lp(F) parport(F) hid_generic usbhid hid usb_storage(F) firewire_ohci firewire_core crc_itu_t(F) ahci(F) libahci(F) e1000e(F) isci libsas(F) mpt2sas raid_class(F) scsi_transport_sas(F)
Aug 21 17:43:47 Z820 kernel: [33464.603152] Pid: 27025, comm: osmocom_siggen Tainted: PF C O 3.8.0-27-generic #40-Ubuntu
Aug 21 17:43:47 Z820 kernel: [33464.603155] Call Trace:
Aug 21 17:43:47 Z820 kernel: [33464.603157] [] warn_slowpath_common+0x7f/0xc0
Aug 21 17:43:47 Z820 kernel: [33464.603171] [] warn_slowpath_fmt+0x4c/0x50
Aug 21 17:43:47 Z820 kernel: [33464.603178] [] ? sched_clock_cpu+0xbd/0x110
Aug 21 17:43:47 Z820 kernel: [33464.603183] [] ? touch_nmi_watchdog+0x80/0x80
Aug 21 17:43:47 Z820 kernel: [33464.603188] [] watchdog_overflow_callback+0x9c/0xd0
Aug 21 17:43:47 Z820 kernel: [33464.603197] [] __perf_event_overflow+0x9d/0x230
Aug 21 17:43:47 Z820 kernel: [33464.603206] [] ? x86_perf_event_set_period+0xd7/0x160
Aug 21 17:43:47 Z820 kernel: [33464.603211] [] perf_event_overflow+0x14/0x20
Aug 21 17:43:47 Z820 kernel: [33464.603221] [] intel_pmu_handle_irq+0x1ab/0x330
Aug 21 17:43:47 Z820 kernel: [33464.603229] [] perf_event_nmi_handler+0x1d/0x20
Aug 21 17:43:47 Z820 kernel: [33464.603234] [] nmi_handle.isra.0+0x59/0x90
Aug 21 17:43:47 Z820 kernel: [33464.603238] [] do_nmi+0xe0/0x360
Aug 21 17:43:47 Z820 kernel: [33464.603244] [] end_repeat_nmi+0x1e/0x2e
Aug 21 17:43:47 Z820 kernel: [33464.603253] [] ? __ticket_spin_lock+0x20/0x30
Aug 21 17:43:47 Z820 kernel: [33464.603258] [] ? __ticket_spin_lock+0x20/0x30
Aug 21 17:43:47 Z820 kernel: [33464.603264] [] ? __ticket_spin_lock+0x20/0x30
Aug 21 17:43:47 Z820 kernel: [33464.603267] <> [] default_spin_lock_flags+0x9/0x10
Aug 21 17:43:47 Z820 kernel: [33464.603277] [] _raw_spin_lock_irqsave+0x2e/0x40
Aug 21 17:43:47 Z820 kernel: [33464.603286] [] bladerf_write+0x18d/0x300 [bladeRF]
Aug 21 17:43:47 Z820 kernel: [33464.603293] [] ? apparmor_file_permission+0x18/0x20
Aug 21 17:43:47 Z820 kernel: [33464.603303] [] ? security_file_permission+0x2c/0xb0
Aug 21 17:43:47 Z820 kernel: [33464.603311] [] vfs_write+0xac/0x180
Aug 21 17:43:47 Z820 kernel: [33464.603315] [] sys_write+0x52/0xa0
Aug 21 17:43:47 Z820 kernel: [33464.603321] [] system_call_fastpath+0x1a/0x1f
Aug 21 17:43:47 Z820 kernel: [33464.603324] ---[ end trace 1031a883afd2f9ce ]---
It is unclear if the warnings and timing errors are mistake on my part when building the image, or if there are problems in the HDL.
7 critical warnings shown below:
Critical Warning (169085): No exact pin location assignment(s) for 1 pins of 139 total pins
Info (169086): Pin fx3_ctl[9] not assigned to an exact location on the device
Info (169086): Pin fx3_ctl[9] not assigned to an exact location on the device
Critical Warning (332012): Synopsys Design Constraints File file not found: '../../fpga/platforms/bladerf/constraints/bladerf.vhd'. A Synopsys Design Constraints File is required by the TimeQuest Timing Analyzer to get proper timing constraints. Without it, the Compiler will not properly optimize the design.
Critical Warning (332012): Synopsys Design Constraints File file not found: '../../fpga/platforms/bladerf/constraints/bladerf.vhd'. A Synopsys Design Constraints File is required by the TimeQuest Timing Analyzer to get proper timing constraints. Without it, the Compiler will not properly optimize the design.
Critical Warning (332148): Timing requirements not met
Info (11105): For details on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.
Info (11105): For details on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.
Critical Warning (332148): Timing requirements not met
Info (11105): For details on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.
Info (11105): For details on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.
Critical Warning (332148): Timing requirements not met
Info (11105): For details on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.
Info (11105): For details on closing timing, run Report Timing Closure Recommendations in the TimeQuest Timing Analyzer.
Forgetting this will cause issues in Windows-land. (This is a TO DO item for this evening).
09:37 < Bzzt_Ploink> one more minor fix static void LIBUSB_CALL
lusb_stream_cb(struct libusb_transfer *transfer) needs
that LIBUSB_CALL there to switch to stdcall instead of the
cdecl standard
In order for the timing analysis to correct determine if the FPGA design meets timing, all inputs and output should be constrained. Altera also recommends using virtual clocks to drive IO constraints, not pin clocks.
Attempting to load the FPGA code within Fedora 19 fails:
[bharrington@leviathan bladeRF]$ bladeRF-cli -p
Backend: libusb
Serial:
USB Bus: 4
USB Address: 12
[bharrington@leviathan bladeRF]$ bladeRF-cli -l ~/Downloads/hostedx40.rbf
INFO - Found a bladeRF
INFO - Claimed all inferfaces successfully
Loading fpga...
INFO - Change to alternate interface 0
INFO - Change to alternate interface 1
Done.
[bharrington@leviathan bladeRF]$
[bharrington@leviathan bladeRF]$
[bharrington@leviathan bladeRF]$ bladeRF-cli -p
Backend: libusb
Serial:
USB Bus: 4
USB Address: 12
[bharrington@leviathan bladeRF]$ bladeRF-cli -l ~/Downloads/hostedx40.rbf
INFO - Found a bladeRF
INFO - Claimed all inferfaces successfully
INFO - Change to alternate interface 1
INFO - Changed into RF link mode: LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED
Loading fpga...
INFO - FPGA is already loaded -- reloading.
INFO - Change to alternate interface 0
INFO - Change to alternate interface 1
Done.
[bharrington@leviathan bladeRF]$ bladeRF-cli -p
Backend: libusb
Serial:
USB Bus: 4
USB Address: 12
[bharrington@leviathan bladeRF]$ rpm -qa libusbx libusbx-devel
libusbx-1.0.16-3.fc19.x86_64
libusbx-devel-1.0.16-3.fc19.x86_64
[bharrington@leviathan bladeRF]$ id
uid=1000(bharrington) gid=1000(bharrington) groups=1000(bharrington),10(wheel),18(dialout),54(lock),985(plugdev),986(wireshark) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[bharrington@leviathan dev]$ ll /dev/nuand /dev/bus/usb/004/012
lrwxrwxrwx. 1 root root 15 Sep 2 23:54 /dev/nuand -> bus/usb/004/012
crw-rw----. 1 root plugdev 189, 395 Sep 3 00:01 /dev/bus/usb/004/012
Use the CLI to automate loading the FPGA via udev rules. Someone wrote a blog about it.
On my TODO list after higher priority items.
To reproduce:
tx config file=/dev/urandom format=csv
tx start
Currently we have dbg_printf compile-time printfs. A more desirable approach would be to have healthy set of logging routines, and a configurable log-level.
int bladerf_log(level, ...);
int bladerf_set_log_verbosity(level);
int bladerf_set_log_output(FILE ); / Optional */
This falls under the "nice to have" category and is a very low priority item.
Currently, items such as samplerate must be entered in units of Hz. A desirable enhancement would be the ability to enter something such as "10M" or "10e6" instead of 10000000.
Be wary of cases such as "10.5M"
IRC log describing issue below. Rob, from my understanding you have some more info on this -- mind updating it here?
10:18 < BzztPloink> but i ran USB30CV which pointed out that set_interface
10:18 < BzztPloink> doesn't set the 'active interface' so calling (set
interface (int:0 alt:0), set interface (int:1 alt:0) in a
row)
10:18 < BzztPloink> doesn't mean 1 is 'active'
10:19 < BzztPloink> set_interface merely sets the alt-setting for the specified
interface
10:19 < BzztPloink> there is not concept of an 'active interface'
10:19 < jynik> ok...lemme jot this down. it's easier not to forget things when
they're staring us in the face on github ;)
10:20 < BzztPloink> i gave mike the cv3 logs already
10:20 < jynik> excellent. I think i recall seeing that link "Chapter 4" or
something..
10:20 < BzztPloink> problem is, the solution is probably to go from 3
interfaces to 1 interface with 3 alt settings
10:20 < BzztPloink> which is going to cause world of hurt driver wise
10:21 < jynik> Linux driver or do you mean in a more general sense?
10:21 < BzztPloink> general sense
10:21 < BzztPloink> fx3 + driver have to be in sync
10:22 < BzztPloink> i see a wrapper call for the set_interface in the near
future that figures out wtf the fx3 is configured with and
does the right call
10:22 < BzztPloink> hmm wait that's not that bad really
Setting the same interface twice in a row will cause the FX3 to be unresponsive due to the FX3 trying to setup the same DMA channel a second time.
The firmware needs to check if we're trying to set the same interface twice in a row.
Currently this defaults to ON, forcing Windows users to manually disable it to get the build working.
I was compiling the FPGA image via the instructions provided in the README, however when I preformed the:
"c) Synthesize FPGA image
i) Processing -> Start Compilation"
step, the following error came up:
Error (10793): VHDL error at bladerf.vhd(7): entity bladerf does not have an architecture
What am I doing wrong?
I am running Quartus 12.01sp1 64-bit on Windows 7 64. I started following the README process with a clean version of the bladeRF repo at revision 55c3879 (latest as of writing this ticket).
Current calls to bladerf_get_sample_rate()
does not return anything. In fact, the rate
pointer is never touched at all.
The rate
should be updated with the current sample rate from the device.
TODO item
Remove -b and make "batch mode" the default. Require user to add -i to drop into interactive mode.
root@ubuntu:/bladeRF/linux/apps# make/bladeRF/linux/apps# exit
Package libbladeRF was not found in the pkg-config search path.
Perhaps you should add the directory containing libbladeRF.pc' to the PKG_CONFIG_PATH environment variable No package 'libbladeRF' found Package libbladeRF was not found in the pkg-config search path. Perhaps you should add the directory containing
libbladeRF.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libbladeRF' found
mkdir -p bin
make -C src/cli
BIN_DIR="/home/geek/bladeRF/linux/apps/bin" CFLAGS="-Wall -Wextra -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -O2 -DNDEBUG" LDFLAGS="" INTERACTIVE=""
make[1]: Entering directory /home/geek/bladeRF/linux/apps/src/cli' cc common.c -Wall -Wextra -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -O2 -DNDEBUG -Icmd -Iinteractive -I. -DINTERACTIVE -c -o common.o In file included from cmd/cmd.h:5:0, from common.c:4: ./common.h:4:24: fatal error: libbladeRF.h: No such file or directory compilation terminated. make[1]: *** [common.o] Error 1 make[1]: Leaving directory
/home/geek/bladeRF/linux/apps/src/cli'
make: *** [bin/cli] Error 2
root@ubuntu:
root@ubuntu:~/bladeRF/linux/apps# uname -a
Linux ubuntu 3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.