aboutsummaryrefslogtreecommitdiffstats
path: root/host/lib/usrp
Commit message (Collapse)AuthorAgeFilesLines
* uhd: Add reference power level API to multi_usrp and radio_controlMartin Braun2020-04-173-0/+98
| | | | | | | | | | | | | | | | | | This adds the following API calls: - multi_usrp::has_{rx,tx}_power_reference() - multi_usrp::set_{rx,tx}_power_reference() - multi_usrp::get_{rx,tx}_power_reference() - radio_control::has_{rx,tx}_power_reference() - radio_control::set_{rx,tx}_power_reference() - radio_control::get_{rx,tx}_power_reference() It also adds a manual page explaining the philosophy of the API. Note that this does not actually add this feature to any device implementation. Calling the new API calls will thus result in `uhd::not_implemented_error` exceptions being thrown. This commit is to lock down the API and ABI.
* b200: Add a prop tree node usb_versionMartin Braun2020-04-141-0/+1
| | | | | At /mboards/0/usb_version, we can now read back an int. It's either 2 or 3, depending on what we're using.
* multi_usrp: Approximate legacy behaviour for recv_async_msg()Martin Braun2020-04-131-5/+29
| | | | | | | | | | | | | When using multi_usrp with an RFNoC device, the previous behaviour was to throw an exception when calling recv_async_msg() so users would know they're not supposed to call it (calling tx_stream::recv_async_msg is preferred). However, this breaks too many existing applications. Instead, we keep a weak pointer to the streamer, the same way that older devices do, and query the async message from that. This means that calling recv_async_msg() when there are multiple streamers can lead to unexpected behaviour, but that's a general issue with multi_usrp::recv_async_msg() and this way, the RFNoC devices now behave like older devices do.
* multi_usrp_rfnoc: Manually pass sample rate to ddc/ducsteviez2020-04-131-0/+14
| | | | | | | | | | | | | | This adds (and calls) methods to manually pass radio block sample rate to the input/output properties of the ddc/duc during creation of the multi_usrp_rfnoc object. The ddc/duc require this information in order to return valid, possible output/input sample rates in get_rx_rates()/get_tx_rates(). Before, the ddc/duc wouldn't have this rate until the rfnoc_graph had been connected and committed, which happens in get_rx_stream()/get_tx_stream(). Thus, this fixes an issue where a user was unable to query possible sample rates prior to specifying a sample rate and creating a stream.
* multi_usrp_rfnoc: Fix get_rx/tx_rates()steviez2020-04-131-12/+10
| | | | | This replaces incorrect code with the proper function calls to retrieve the range of possible sample rates.
* fixup! uhd: Add fuzzy serial number checkingmattprost2020-04-091-1/+1
|
* uhd: mpm: Query prefs per-device for multi-device queriesLane Kolbly2020-04-082-2/+15
| | | | | | | If a user specifies a multi-device query, such as "serial0=1234,serial1=4321", we have to look up the preferences for each device. To minimize the impact to non-x400 devices, I simply push the get_usrp_args call down into mpmd_impl and mpmd_find.
* uhd: Add fuzzy serial number checkingLane Kolbly2020-04-081-1/+2
| | | | | | | | | We have integer 32-bit serial numbers for MPM devices, for example "1234abcd". For serial numbers which have less than eight digits, e.g. "123abcd", a user may feel inclined to prefix this number with a 0 when they are searching for devices, e.g. "0123abcd". This change makes it so that specifying "0123abcd" will match a device with serial number "123ABCD".
* uhd: cal: Use usrp::cal::database instead of CSV filesMartin Braun2020-04-021-167/+128
| | | | | | | | | Now that we have cal::iq_cal and cal::database, there's no need to manually wrangle CSV files for calibration data. This commit replaces all CSV operations with cal::database calls and uses cal::iq_cal as a container. CSV files can still be read, but are considered deprecated.
* multi_usrp: Fix ALL_CHAN and ALL_MBOARDS API calls for Gen-3 devicesMartin Braun2020-03-311-105/+64
| | | | | | | | Most of the API calls that default an arg to ALL_CHANS or ALL_MBOARDS were in fact broken. This adds a macro to efficiently mux out API calls that take such wildcard arguments so we don't have to repeat the same loop all over the place, even for those API calls that already correctly implemented wildcards (for consistency).
* fixup! x300: lf/basic antenna API implementationMartin Braun2020-03-261-2/+2
|
* x300: lf/basic antenna API implementationmattprost2020-03-234-110/+234
| | | | | | | | | | | | | | | | This results in a change of operation for LF/Basic Boards on X300/X310 devices. The RX streaming mode will now be specified by the antenna rather than the subdev: (AB or BA for complex streaming, and A or B for real-mode streaming, with AB being the default antenna value). For real-mode streaming, data is collected as complex data with zeroed-out values in the quadrature domain. The subdevs for these boards have been changed to 0 and 1 for the RX channels, and 0 for the TX channel, in order to align with subdev specs of other RFNoC devices. Note: the old streaming mode paradigm is still in place for the N210.
* multi_usrp: Provide valid return value for multi_usrp::get_device()Martin Braun2020-03-121-3/+51
| | | | | | | | | | | | For RFNoC devices, multi_usrp::get_device() no longer returns a device pointer, rather, it returns a nullptr. This is intentional because access to the underlying device is no longer allowed. However, legacy code can segfault (e.g. portions ofr gr-uhd). This patch returns a faux uhd::device class, which almost mimicks the original behaviour perfectly, by redirecting its class methods back to multi_usrp_rfnoc. The only exception is recv_async_msg(), which requires a TX streamer. This function will always return false now.
* utils/C API: Fix property tree accessMartin Braun2020-03-121-4/+4
| | | | | | | | | | The introduction of multi_usrp_rfnoc caused multi_usrp::get_device()->get_tree() to segfault for gen3 devices. In defcb174, we introduced a fix for this (multi_usrp::get_tree()) but we didn't apply it to internal utilities. That means the uhd_cal_* utilties were broken, along with certain sections of the C API, and the latency test suite. This fixes the segfault issue.
* uhd: Apply clang-format against all .cpp and .hpp files in host/Martin Braun2020-03-03173-15372/+17286
| | | | | Note: template_lvbitx.{cpp,hpp} need to be excluded from the list of files that clang-format gets applied against.
* x300: add front-panel GPIO source controleklai2020-02-185-43/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds a ZPU register to control the FP GPIO source. These are 2bits per GPIO pin, totalling 24 bits. 0 corresponds to RF-A, 1 corresponds to RF-B. The following Python code will control the upper 6 bits of the front-panel GPIO from the B-side radio on an X300: >>> import uhd >>> U = uhd.usrp.MultiUSRP("type=x300") >>> U.get_gpio_src_banks() ['FP0'] >>> U.get_gpio_src("FP0") ['RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA'] >>> U.set_gpio_src("FP0", ['RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFB', 'RFB', 'RFB', 'RFB', 'RFB', 'RFB']) >>> U.get_gpio_src("FP0") ['RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFA', 'RFB', 'RFB', 'RFB', 'RFB', 'RFB', 'RFB'] >>> # Make all GPIOs outputs: >>> U.set_gpio_attr("FP0A", "DDR", 0xFFF) >>> U.set_gpio_attr("FP0B", "DDR", 0xFFF) >>> # Control all GPIOs from software (not ATR): >>> U.set_gpio_attr("FP0A", "CTRL", 0x000) >>> U.set_gpio_attr("FP0B", "CTRL", 0x000) >>> # Bottom 3 pins go high from radio A >>> U.set_gpio_attr("FP0A", "OUT", 0x007) >>> # Top 3 pins go high from radio B >>> U.set_gpio_attr("FP0B", "OUT", 0xE00) Amends the gpio.cpp example to allow switching the source. Co-authored-by: Brent Stapleton <brent.stapleton@ettus.com>
* ad9361: Fix formattingMartin Braun2020-02-101-13/+10
| | | | | - Apply clang-format - Remove unnecessary boost::format
* multi_usrp: Add get_tree() API callMartin Braun2020-02-042-0/+10
| | | | | | This allows access to the underlying property tree without having to refer to the device object. Useful for RFNoC objects, where the device object is not accessible.
* multi_usrp: Amend APIs for GPIO source controlMartin Braun2020-01-232-1/+12
| | | | | | | | | | | This adds a new API call to multi_usrp: get_gpio_src_banks(). This returns a list of GPIO banks who's source can be controlled through the motherboard controller. The remaining GPIO source methods' docstrings are improved, to explain the difference between GPIO banks for set_gpio_attr() and set_gpio_src(). The former controls the actual value on a GPIO bank, and the latter who drives it. These can be different banks.
* mpm/mpmd: Expose APIs to drive GPIO sourcesMartin Braun2020-01-231-0/+40
| | | | | | | | | | | | | | | | | | | The N310 has a feature that allows the front panel GPIOs to be driven by various sources: The PS, or any of the radio channels. The MPM-based APIs did not expose any way to change that. Changes: - Add MPM APIs to PeripheralManagerBase and n3xx classes - Improve comments and explanations - Add host-side hooks into these new APIs in mpmd_mb_controller - Implement these APIs for N3xx The N3xx devices will have the option to set the GPIO source to "PS", or to one of "RF0", "RF1", "RF2", "RF3" (if there are four channels; the N300 and N320 can only go up to RF1). Note: The N310 radio does not have separate FP-GPIO banks for channels 0 and 1, which needs to be fixed in a separate commit.
* mpmd: Use dpdk_simple for MTU discoveryAlex Williams2020-01-221-91/+16
| | | | And delete the stale code for the DPDK-specific version.
* x300: Remove early x300_device_args usageAlex Williams2020-01-221-7/+6
| | | | | | | | Args were being parsed in x300_eth_manager::find(), before UHD could ascertain the args were intended for an X300 device (and not some other device). This caused unwarranted error messages to print in some cases. The changes here fix this and prevent the premature parsing and error messages.
* cmake: Find DPDK via pkg-config, if availableAlex Williams2020-01-222-1/+3
| | | | | | Debian uses pkg-config without the libdpdk.so linker script. Use the pkg-config file to grab the installed libraries and determine what to link to.
* uhd: fixing MSVC warningsBrent Stapleton2020-01-093-14/+23
| | | | | | | | | | | Small changes to remove various compiler warnings found in MSVC - Adding uhd::narrow_cast to verious spots - wavetable.hpp: all floats literals in the wavetable. - paths_test: unnecessary character escape - replay example: remove unreferenced noc_id - adfXXXX: Fixing qualifiers to match between parent and derived classes - rpc, block_id: Removing unused name in try...catch
* uhd: Correct rx/tx EEPROM typoToni Jones2020-01-071-5/+5
| | | | Correct a typo differentiating RX and TX EEPROM paths.
* multi_usrp: unify GPIO access typeBrent Stapleton2019-12-301-1/+1
| | | | | | | | GPIOs in the property tree are registered as uint32_t's, so the get_gpio_attr function should use that type as well. This resolves a property tree runtime_error when running the `gpio` example with a B2xx device.
* usrp: Change default number of data frames for X300Ciro Nishiguchi2019-12-201-16/+20
| | | | | | Change the default number of frames so that it works well when using offload threads, including DPDK. This matches the default number of frames in mpmd.
* transport,usrp: Make available packet-based flow controlAlex Williams2019-12-206-44/+59
| | | | | | | | DPDK provides a fixed number of fixed-size buffers for the receive window, so it needs packet-based flow control to avoid dropping packets. This change enables counting by packets. Co-authored-by: Ciro Nishiguchi <ciro.nishiguchi@ni.com>
* usrp: Add I/O service manager for DPDKCiro Nishiguchi2019-12-202-0/+24
|
* x300,mpmd: Enable DPDKMartin Braun2019-12-2012-465/+216
| | | | | | | | | | | | | | x300: - Remove obsolete variables from x300_eth_mgr and X300 motherboard components - Added some documentation / comments - Use constrained device args in more places - Enables the use of use_dpdk=1 - Switches between regular (kernel-based) and DPDK UDP mpmd: - Merge link_if_ctrl for udp and dpdk_udp - Update cmake options
* e31x: Fix filter bank and antenna switching for channel 0Sugandha Gupta2019-12-023-43/+60
| | | | | | The filter bank and antenna switches have different configuration for channel 0 and channel 1. This commit fixes the issue where channel 0 produces only noise due to incorrect switches.
* mpmd: Name the claimer task threadMartin Braun2019-11-261-13/+15
| | | | | We call set_thread_name() on the claimer loop so the thread can be identified using OS utilities.
* x300: pcie manager updatesVirendra Kakade2019-11-262-129/+93
| | | | Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
* mg: Turn the set-lock into a recursive mutexMartin Braun2019-11-262-15/+15
| | | | | Individual API calls might have to call each other (e.g., like set_rate() will call set_rx_frequency()), which would cause a deadlock.
* mg: Always set MCR on both daughterboardsMartin Braun2019-11-263-12/+33
| | | | | | | | | | | | | | | | | The N310 cannot set the MCR for its daughterboards separately. This patch modifies the radio block controller such that any block controller, when requested to change the master clock rate, will first change Radio 0, and then Radio 1. This fixes the following issues: - In multi_usrp, calling set_master_clock_rate() will not necessarily call set_rate() on the radios in any particular order, which will break when calling Radio 1 first - In RFNoC apps, it wasn't possible to run off of slot B alone without this change. Note: When calling set_rate() on one radio, the other radio is in an invalid state until its set_rate() is also called.
* mpmd: Fix get_mboard_name()Martin Braun2019-11-261-1/+1
| | | | | It used to produce the individual name of the USRP, but it should return a product name.
* n310: Fix GPIO registersMartin Braun2019-11-261-3/+6
| | | | | This enables the use of the dboard and FP GPIOs. The problem was that the register offset of 8 was not encoded.
* mg/rh/rfnoc: Harmonize peripheral registersMartin Braun2019-11-263-18/+29
| | | | | - Move the SPI addresses out of radio_control_impl - Fix the GPIO address spaces for N310/N300
* gpio_atr_3000: Fix return value for pin control registerMartin Braun2019-11-261-1/+3
| | | | | | | | | | | | | | | This fixes a bug where get_gpio_attr(bank, "CTRL") would return the inverted value of what was written. Reason is that the underlying register was an ATR disable register. The fix is to invert the cached values of the register. Now, the following Python code will work: >>> U = uhd.usrp.MultiUSRP("type=x300") >>> atr_enable = 0xF # Enable ATR on lower 4 pins, rest is GPIO >>> U.set_gpio_attr("FP0A", "CTRL", atr_enable) >>> U.get_gpio_attr("FP0A", "CTRL") == atr_enable True
* e310: Fix issues in MPM and UHDMartin Braun2019-11-261-7/+3
| | | | | | | | | | | - Remove superfluous INFO logging - Improve formatting in many places - Improve Pylint score in various places - Add tear_down to DB object - Simplify custom EEPROM code for E310 - Fix time source selection code - Remove references to GPS_CTRL and GPS_STATUS (are E320 only) - Move clock source control out of MboardRegs object
* mpm/mpmd: Remove token requirement for device infoMartin Braun2019-11-261-2/+2
| | | | | This removes the token requirement for get_proto_ver() and get_chdr_width().
* rfnoc: Rename thread affinity argsCiro Nishiguchi2019-11-262-49/+52
| | | | | | Rename thread affinity args such that they do not end with an integer. Arg names ending with an integer are interpreted as being targeted at a specific motherboard index in device_addr methods.
* lib,tests: Remove old DPDK files from buildAlex Williams2019-11-261-7/+8
| | | | The DPDK files are left behind as a reference, for now.
* rfnoc_graph: Modify find_blocks() to sort return valueMartin Braun2019-11-261-35/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this patch, the elements of of the return value of find_blocks() are sorted lexicographically (specifically, using uhd::rfnoc::block_id_it::operator<()). The underlying block_container class stores the blocks in an unordered set, so the return value for find_blocks() was always sorted randomly. multi_usrp_rfnoc had to sort the return values every time find_blocks() was used to get a useful return value. Because find_blocks() had no contract for the order of returned blocks, this change simply sorts the return value before returning it. multi_usrp_rfnoc is modified to remove all the sorts that are now superfluous. A good way to see the change is to run uhd_usrp_probe, which will now contain content like this: | _____________________________________________________ | / | | RFNoC blocks on this device: | | | | * 0/DDC#0 | | * 0/DDC#1 | | * 0/DUC#0 | | * 0/DUC#1 | | * 0/DmaFIFO#0 | | * 0/Radio#0 | | * 0/Radio#1 Assuming the blocks don't change, the order of this list will always be the same following this patch. Note that the order is unrelated to the order on the control crossbar, which it never was.
* multi_usrp: Fix GPIO bank selectionMartin Braun2019-11-261-11/+68
| | | | | | | | | | When calling a multi_usrp object like this: usrp->set_gpio_attr("TXB", "CTRL", 0xFFFF); Previously, it would only be able to address daughterboard A. Now, there is a full backward-compatible solution (compatible with 3.15), that will address either daughterboard's GPIOs.
* liberio: porting to I/O servicesBrent Stapleton2019-11-261-11/+2
| | | | Fixes 85f0551 ("rfnoc: Add I/O service manager to X300 and MPMD")
* multi_usrp: Add set_rx_spp() callMartin Braun2019-11-262-2/+34
| | | | | | | | This API call is a more explicit way of setting the spp than passing in an spp value in the args of the stream args when creating streamers. For pre-RFNoC devices, this is done by injecting the spp arg back into the stream args. For RFNoC devices, the set_property() call on the radio is called.
* rfnoc: Restrict to inline I/O service based on link restrictionsCiro Nishiguchi2019-11-261-1/+33
| | | | | For links that do not support releasing buffers out of order, restrict the I/O service manager to always select the inline I/O service.
* rfnoc: Use graph_utils in multi_usrp chan generationBrent Stapleton2019-11-261-113/+142
|
* rfnoc: Merge I/O service device args with stream argsCiro Nishiguchi2019-11-264-42/+113
| | | | | This makes it possible for users to put I/O service-related args in either the device args or stream args.