srenblad
/
artiq
forked from M-Labs/artiq
1
0
Fork 0
Code Pull Requests Activity

manual: artiq.coredevice.runtime_exceptions -> artiq.coredevice.exceptions

This commit is contained in:
Sebastien Bourdeauducq 2016-01-13 14:40:44 -07:00
parent e4996fed92
commit adf552e8d1
2 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/manual/core_drivers_reference.rst
View File

@ -24,8 +24,8 @@ These drivers are for the core device and the peripherals closely integrated int
.. automodule:: artiq.coredevice.dds .. automodule:: artiq.coredevice.dds
:members: :members:
:mod:`artiq.coredevice.runtime_exceptions` module :mod:`artiq.coredevice.exceptions` module
------------------------------------------------- -----------------------------------------
.. automodule:: artiq.coredevice.runtime_exceptions .. automodule:: artiq.coredevice.exceptions
:members: :members:

4
doc/manual/getting_started_core.rst
View File

@ -110,11 +110,11 @@ Create a new file ``rtio.py`` containing the following: ::
Connect an oscilloscope or logic analyzer to TTL0 and run ``artiq_run.py led.py``. Notice that the generated signal's period is precisely 4 microseconds, and that it has a duty cycle of precisely 50%. This is not what you would expect if the delay and the pulse were implemented with CPU-controlled GPIO: overhead from the loop management, function calls, etc. would increase the signal's period, and asymmetry in the overhead would cause duty cycle distortion. Connect an oscilloscope or logic analyzer to TTL0 and run ``artiq_run.py led.py``. Notice that the generated signal's period is precisely 4 microseconds, and that it has a duty cycle of precisely 50%. This is not what you would expect if the delay and the pulse were implemented with CPU-controlled GPIO: overhead from the loop management, function calls, etc. would increase the signal's period, and asymmetry in the overhead would cause duty cycle distortion.
Instead, inside the core device, output timing is generated by the gateware and the CPU only programs switching commands with certain timestamps that the CPU computes. This guarantees precise timing as long as the CPU can keep generating timestamps that are increasing fast enough. In case it fails to do that (and attempts to program an event with a timestamp in the past), the :class:`artiq.coredevice.runtime_exceptions.RTIOUnderflow` exception is raised. The kernel causing it may catch it (using a regular ``try... except...`` construct), or it will be propagated to the host. Instead, inside the core device, output timing is generated by the gateware and the CPU only programs switching commands with certain timestamps that the CPU computes. This guarantees precise timing as long as the CPU can keep generating timestamps that are increasing fast enough. In case it fails to do that (and attempts to program an event with a timestamp in the past), the :class:`artiq.coredevice.exceptions.RTIOUnderflow` exception is raised. The kernel causing it may catch it (using a regular ``try... except...`` construct), or it will be propagated to the host.
Try reducing the period of the generated waveform until the CPU cannot keep up with the generation of switching events and the underflow exception is raised. Then try catching it: :: Try reducing the period of the generated waveform until the CPU cannot keep up with the generation of switching events and the underflow exception is raised. Then try catching it: ::
from artiq.coredevice.runtime_exceptions import RTIOUnderflow from artiq.coredevice.exceptions import RTIOUnderflow
def print_underflow(): def print_underflow():