ADF41513/0 and ADRF5702/3 support - #764
Conversation
Recommend the usage of a virtual environment instead of: 'sudo pip install' Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
|
Generated documentation for this PR is available at Link |
IIO Context Coverage ReportNew device classes in this PR: adf41510, adf41513, adf4151x Minimum required total coverage: 75.0% Summary
Untested attributes (click to expand)adf41513
Generated by IIO Context Coverage workflow |
tfcollins
left a comment
There was a problem hiding this comment.
Your compatible.py functionality already exists here https://github.com/analogdevicesinc/pyadi-iio/blob/main/adi/device_base.py
Your class should also not have so many register based operations. These should be debug attributes in the driver.
The devices covered here are not tx/rx devices. Also, device_base does not initializes shared_def. Will see if I can integrate compatible features into device_base.
will drop the register based properties for now. |
Add features to device_base, so that it covers both wrapper-mode (rx_chan_comp / tx_chan_comp) and standalone-mode (attribute-only control devices) use. - Add device_base.variant() staticmethod. Creates a derived class pinned to a specific compatible part and appends the part to compatible_parts. Supports per-part chip_info via **kwargs stored in the new _device_info class dict. - Extend __init__ to accept an optional uri argument. When provided, device_base drives shared_def.__init__ itself and resolves _ctrl. When omitted (wrapper mixin path), _control_device_name is set for the wrapper's rx_def/tx_def to consume as before. - In URI mode, device_name may be a driver name, a device label, or an IIO device id. libiio's find_device handles all three. If it can't resolve (or _control_device_name is left empty to signal "match any compatible"), fall back to scanning ctx.devices against compatible_parts. - Normalize device_name to the resolved _ctrl.name after discovery so per-part _device_info lookup and _rx/tx_data_device_name assignments use the actual driver name. - Validate the resolved _ctrl.name against compatible_parts (or the variant-pinned _device_name subset) before applying chip_info. - device_index is honored only in the wrapper path (via shared_def); on the URI path, disambiguate multiple devices using a label or id instead. Wrapper classes (tx_chan_comp, rx_chan_comp, tx_chan_comp_no_buff, rx_chan_comp_no_buff) are unchanged; they continue to call device_base.__init__ without a uri and let rx_def / tx_def perform the shared_def initialization.
- Leveraging device_base class for multi-device support; - register and muxout definitions for debug; Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Leverage the device_base class and add adrf5702 and adrf5703 to compatible parts list. Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
ADF41513/0 and ADRF5702/3 support
Adds driver support for the ADF41513/0 PLL frequency synthesizers and extends the
ADRF5720 digital attenuator to cover the ADRF5702 and ADRF5703. Both additions
are built on a new features of the device_base class, which allows for multi-part compatible
device handling.
adi.adf4151x — driver for the ADF41513/0 26.5 GHz Integer-N/Fractional-N PLL,
exposing output frequency, frequency resolution, powerdown.
adi.adrf5720 — compatible_parts now includes adrf5702 and adrf5703 alongside the
existing adrf5720, adrf5730, and adrf5731.
References:
Type of change
How has this been tested?
State explicitly whether this was tested against real hardware, an emulated context (iio-emu), or not run. Name the part(s) and the context URI or board used.
python3 -m pytest -k ad4080 --adi-hw-map):python -m pytest test/test_adf41513.py --uri ip:10.32.22.147 --skip-scanpytest --emu --skip-scan test/test_adf41513.pyTest configuration
Documentation
doc/source/New device class interfaces
Skip this section if the PR does not add a new device class.
adi.device_base(rx_chan_comp,tx_chan_comp, or a_no_buffvariant). If not, explain why in the description. See the Device Base Classes developer doc page.compatible_partslists every part number this class supportssupported_parts.md(verify withinvoke checkparts)test/emu/and referenced from a testChecklist
invoke precommitpasses locallySigned-off-by: Name <email>)