ad9213 dev pyadi - #770
Conversation
Signed-off-by: PopPaul2021 <Paul.Pop@analog.com>
Finished adding pyadi-iio support for ad9213. The branch was created based on: https://github.com/analogdevicesinc/pyadi-iio/tree/ad9213_dev Signed-off-by: Tudor-andrei-Ticudean_adi <Tudor-andrei.Ticudean@analog.com>
Keep validated ad9213 driver implementation based on real hardware (iio_info from VCU118 + AD9213). Main had an unvalidated stub using rx_def and axi-ad9213-rx-hpc which does not exist on actual hardware. Signed-off-by: Tudor-andrei-Ticudean <Tudor-andrei.Ticudean@analog.com>
IIO Context Coverage ReportNew device classes in this PR: (adis16375, adis16480, adis16485, adis16488 Minimum required total coverage: 75.0% Summary
Untested attributes (click to expand)adis16480
Generated by IIO Context Coverage workflow |
|
Generated documentation for this PR is available at Link |
a988269 to
9701afc
Compare
9701afc to
a988269
Compare
Signed-off-by: Tudor-andrei-Ticudean <Tudor-andrei.Ticudean@analog.com>
a988269 to
28b848b
Compare
|
The driver naming here of |
tfcollins
left a comment
There was a problem hiding this comment.
The driver naming seems off. Please consult with the Linux team here.
Checked the ADI Linux dev branch ad9213_check, in drivers/iio/adc/ad9213.c the device name is hardcoded as "ad9213" (line 692) and the DT compatible is "adi,ad9213". Note this branch is still in development and not yet upstream. I think this might follow the SPI device convention rather than the AXI core axi--rx-hpc naming, but I'm not sure, happy to update if needed or ask the Linux team. Update: I asked the person that created the PR about the naming. From what I understand it should be parsed from device tree and not hardcoded. Update 2: Person answered: The ad9213 does not use "axi_adc", it uses "iio_backend" so the naming should be correct in this case. Maybe it could be named to "ad9213_phy" to be more precise. |
tfcollins
left a comment
There was a problem hiding this comment.
Can to address the inheritance usage question of rx vs rx_def
|
|
||
| from adi.context_manager import context_manager | ||
| from adi.rx_tx import rx_def | ||
| from adi.rx_tx import rx |
There was a problem hiding this comment.
Keep rx_def. It has more supported features
| """sampling_frequency: Sample rate of the ADC in Hz.""" | ||
| return self._get_iio_attr("voltage0", "sampling_frequency", False, self._rxadc) | ||
|
|
||
| def ad9213_register_read(self, reg): |
There was a problem hiding this comment.
this should be called just register_read. We already know its a ad9213
|
|
||
| class ad9213(rx_def, context_manager): | ||
| """ AD9213 High-Speed ADC """ | ||
| class ad9213(rx, context_manager): |
There was a problem hiding this comment.
Why are you using the rx class directly here vs the rx_def? rx_def would give you more functionality.
Signed-off-by: Tudor-andrei-Ticudean <Tudor-andrei.Ticudean@analog.com>
Description
Add PyADI support for ad9213 based on already-existing: https://github.com/analogdevicesinc/pyadi-iio/tree/ad9213_dev
Fixes # (issue)
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):-- pytest test/test_ad9213.py -v
-- python3 examples/ad9213_example.py
Test 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>)