* ad9910: fix asf range
The ASF is a 14-bit word. The highest possible value is 0x3fff, not
0x3ffe. `int(round(1.0 * 0x3fff)) == 0x3fff`.
I don't remember and understand why this was 0x3ffe since the beginning.
0x3fff was already used as a default in `set_mu()`
Signed-off-by: Robert Jördens <rj@quartiq.de>
* RELEASE_NOTES: ad9910 asf scale change
Co-authored-by: David Nadlinger <code@klickverbot.at>
* Input validation and masking of SI -> mu conversions (close#1446)
Signed-off-by: Marius Weber <marius.weber@physics.ox.ac.uk>
* Update RELEASE_NOTES
Signed-off-by: Marius Weber <marius.weber@physics.ox.ac.uk>
Co-authored-by: Robert Jördens <rj@quartiq.de>
* ad53xx: voltage_to_mu() validation & documentation (closes#1443, #1444)
The voltage input (float) is checked for validity. If we need more
speed, we may want to check the DAC-code for over/underflow instead.
Signed-off-by: Marius Weber <marius.weber@physics.ox.ac.uk>
* ad53xx documentation: voltage_to_mu is only valid for 16-bit DACs
Signed-off-by: Marius Weber <marius.weber@physics.ox.ac.uk>
* AD53xx: add voltage_to_mu method (closes#1341)
Signed-off-by: Marius Weber <marius.weber@physics.ox.ac.uk>
* ad53xx: improve voltage_to_mu performance
Interger comparison is faster than floating point math.
Signed-off-by: Marius Weber <marius.weber@physics.ox.ac.uk>
* AD53xx: voltage_to_mu method now uses attribute values
Signed-off-by: Marius Weber <marius.weber@physics.ox.ac.uk>
* Fixup RELEASE_NOTES.rst
Signed-off-by: Marius Weber <marius.weber@physics.ox.ac.uk>
* ad53xx: documentation improvements
voltage_to_mu return value
14-bit DAC support
Signed-off-by: Marius Weber <marius.weber@physics.ox.ac.uk>
* This targets unrelease CPLD gateware (https://github.com/quartiq/mirny/issues/1)
* includes initial coredevice driver, eem shims, and kasli_generic tooling
* addresses the ARTIQ side of #1130
* Register abstraction to be written
Signed-off-by: Robert Jördens <rj@quartiq.de>
This removes:
* host-side keepalive, which turns out not to be required
* custom connection timeout (the default is OK)
* SSH tunneling support (doesn't seem to be actually used anywhere)
* updated adoo10.py for RAM mode frequency control
* updated docstrings for set_cfr1() in ad9910.py
* fixed typo in ad9910.py
* added docstrings to ad9910.py
* removed OSK-related changes in AD9910, to be included in a separate branch.
* updated AD9910 set_cfr1 for control of OSK mode parameters
* updated AD9910 set_cfr1() for control of OSK mode parameters.
This hopefully suggests a bit better that the value is the last one
fetched by the servo (i.e. needs the servo active to update), rather
than somehow requesting a new sample to be taken.
As already mentioned in the gateware.
One alternative would be to detect address collisions and
stall the read for one cycle.
Note that there will in general not be a consistent view of the servo
state unless the servo is stopped.
close#1337
async is now a full (non-contextual) keyword.
There are two more instances:
- artiq/frontend/artiq_client.py
- artiq/devices/thorlabs_tcube/driver.py
It is not immediately clear how to fix those, so they are left for
later work.
This is difficult to test without hardware mocks or some
form of phase readback, but the symptom was that e.g.
`self.dds.set(…, ref_time=now_mu() - 1)` would fail
periodically, that is, whenever bit 32 of the timestamp
would be set (which would be turned into the sign bit).
This is a fairly sinister issue, and is probably a compiler
bug of some sort (either accepts-invalid or wrong type inference).
Previously the TSC was truncated to an even coarse RTIO periods before doing
the setting SPI xfer. Afterwards the the IO update pulse would introduce
at least one but less than two RTIO cycles. Ultimately the RTIO TSC was
truncated again to even. If the SPI xfer takes an odd number of RTIO
periods, then a subsequent xfer would collide.
close#1229
Signed-off-by: Robert Jördens <rj@quartiq.de>
* ad9910: finish CONT_RECIRCULATE -> CONT_RAMPUP
Found while building docs. Forgot to refactor strings.
Signed-off-by: Drew Risinger <drewrisinger@users.noreply.github.com>
* spi2: reformat update_xfer_duration_mu docstring
update_xfer_duration_mu docstring threw warning while building docs,
didn't use consistent indent in warning.
Signed-off-by: Drew Risinger <drewrisinger@users.noreply.github.com>
This now reliably locates the SYNC_CLK-IO_UPDATE edge by doing two
scans at different delays between start and stop IO_UPDATE.
It also works well when one delay is very close to the edge.
And it correctly identifies which (start or stop) pulse hit or crossed
the SYNC_CLK edge.
for #1143
Signed-off-by: Robert Jördens <rj@quartiq.de>
* simplified and cross-referenced the explanation of the different
phase modes.
* semantically and functionally merged absolute and tracking/coherent
phase modes.
* simplified numerics to calculate phase correction
* added warning about possible inconsistency with DMA and default
phase mode
* restricted __all__ imports
* moved continuous/relative phase offset tracking from an instance
variable to a "handle" returned by set()/set_mu() in order to avoid
state inconsistency with DMA (#1113#1115)
for #1143
Signed-off-by: Robert Jördens <rj@quartiq.de>
* expose multi device sync functionality
* sync delay configuration interface
* auto-tuning of sync delay from device_db seed
for #1143
Signed-off-by: Robert Jördens <rj@quartiq.de>
These methods are problematic, as with DMA in the picture, the
timestamp member variables did not necessarily reflect the last
submitted event timestamp (see GitHub #1113).
sync() is only very rarely used in typical experimental code, so
the methods are removed without a transition period.
Core.wait_until() can be used to busy-wait for a specified RTIO
timestamp value on the core device CPU instead.
The code currently doesn't compile because of a typo in the timestamp
field name. However, tracking event timestamps in software is
problematic anyway (e.g. with DMA, see GitHub #1113), so just remove
`sync()` altogether.
