| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
No code changes, only comment changes.
|
|
|
|
|
|
|
|
|
| |
No functional changes whatsoever, only:
- Move DioControl to its own module (x4xx_dio_control.py)
- Where PyLint was complaining about whitespace issues, fix those
- Fix import list in x4xx_periphs.py after removing DioControl
- Fix import list in x4xx.py to import DioControl from the correct
location
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The X4x0 MPM code doesn't always load the object for the DIO control, it
only does that when certain checks pass (EEPROM readouts need to match
expected values). Therefore, `self.dio_control` may be NoneObject during
operations, and in other areas of the code, we already check if that's
the case.
The APIs added in c36fc5f don't have these checks, which means accessing
these new APIs may result in odd exceptions when trying to dereference
a NoneType object. By adding checks for the initialization state of
`self.dio_control`, we can avoid these and either substitute better
error messages / exception messages, or return safe values.
Note that mpmd_mb_controller also accesses this object indirectly by
checking the length of the return value of get_gpio_banks(). This check
is not affected by this change, as we now are guaranteed to return an
empty list if there is no self.dio_control.
|
| |
|
|
|
|
| |
Signed-off-by: Virendra Kakade <virendra.kakade@ni.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The external power can, broadly speaking, be in one of three possible
states:
- OFF (the default)
- ON (the user has enabled external power, and it's working normally)
- FAULT (the external power has encountered a fault condition)
This commit allows the client of MPM to distinguish between these
three conditions.
|
|
|
|
|
|
| |
These methods allow for reconfiguration of GPIO masters for x4xx.
The method names are get_gpio_banks, get_gpio_srcs, get_gpio_src,
and set_gpio_src.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So, the Python garbage collector is a bit pernicious, in that it happens
behind the scenes in a way which is difficult to predict. The rfdc_ctrl
class expects that its "lifetime" will be a single live/die cycle of the
FPGA (i.e. that when a new FPGA is loaded, it will be destructed).
However, by default the Python GC will keep the X4xxRfdcCtrl class alive
for an arbitrary amount of time, meaning that it's possible that
multiple (C++) rfdc_ctrl classes can be alive at a single time.
When the GC reaps all of these classes, libmetal segfaults when we call
metal_finish several times in a row. This change works around that
issue, if not the overall GC issue, by explicitly deleting the rfdc_ctrl
object.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
There currently isn't a way to access the motherboard register using MPM
(the ones defined in x4xx_global_regs). This commit adds a simple
interface to peek and poke them which is very similar to the current
interface for the daughter board registers.
Signed-off-by: Sam O'Brien <sam.obrien@ni.com>
|
| |
|
|
|
|
|
|
|
|
| |
This fixes an issue where the slot 0 ADC blocks would erroneously
report that they were unfrozen.
Additionally, adds logic to restore a saved cal freeze state on
sync source change.
|
|
|
|
| |
After setting sync sources, the RFDCs get reset, we need to restore the previously set frequencies so that the device continues to transmit/receive at the requested frequency
|
|
Co-authored-by: Lars Amsel <lars.amsel@ni.com>
Co-authored-by: Michael Auchter <michael.auchter@ni.com>
Co-authored-by: Martin Braun <martin.braun@ettus.com>
Co-authored-by: Paul Butler <paul.butler@ni.com>
Co-authored-by: Cristina Fuentes <cristina.fuentes-curiel@ni.com>
Co-authored-by: Humberto Jimenez <humberto.jimenez@ni.com>
Co-authored-by: Virendra Kakade <virendra.kakade@ni.com>
Co-authored-by: Lane Kolbly <lane.kolbly@ni.com>
Co-authored-by: Max Köhler <max.koehler@ni.com>
Co-authored-by: Andrew Lynch <andrew.lynch@ni.com>
Co-authored-by: Grant Meyerhoff <grant.meyerhoff@ni.com>
Co-authored-by: Ciro Nishiguchi <ciro.nishiguchi@ni.com>
Co-authored-by: Thomas Vogel <thomas.vogel@ni.com>
|