nidigital should expose sites as repeated capabilities

[marcoskirsch]

This is up for discussion.
I believe sites in nidigital should be repeated capabilities similar to how we do channels.

my_session.sites[[3,4]]. fetch_capture_waveform("my_waveform", 1024)

[sbethur]

Depending on whether we make sites a repeated capability or not, the type for sites in write_source_waveform_site_unique and fetch_capture_waveform may need to change.

siteList in C API is a const string. Its contents are Site numbers listed as a comma-delimited list of strings of form siteN, where N is the site number.

Currently, type of sites in write_source_waveform_site_unique and fetch_capture_waveform, at public Python API layer, is int. We internally convert it to "site0,site1...", as required.

When working on this issue, we should ensure the type is kept consistent at the Python API layer.

[sbethur]

If sites is not made a repeated capability, we should make site_list parameter in public methods optional by giving it a default value of '' i.e. empty string, which means all sites.

[sbethur]

There are a bunch of methods that accept a site list as "site0,site1,site2". These could easily be made more usable by making sites a rep-cap (with "site" as prefix). Users would be able to write code like:

session.sites[0,1].burst_pattern("pat", true)

Then there are methods that accept a single site as "site0". Should we update these methods to treat site as a rep-cap? ..so users can write something like:

session.sites[0].fetch_history_ram_cycle_information(0, 0)

and let the driver return an error if they specify more than one site?

Then there are methods that expect a pinList. The pin list can include "site-restricted" pins like site0/PinA. To make this easier to use we can allow users to specify both sites and pins and pins as repeated capabilities. It would be something like:

session.sites[2].pins['VCC,CLK'].ppmu_voltage_level = 4

We need to figure out the usability and implementation feasibility of something like above.