PnCConf rework

Daughterboard hints are just part of the XML file (they dont need to come from the hardware)
In any case the user must still specify which daughtercards are connected where,
as there are multiple different daughtercards that can use the same FPGA configuration so the
user _must_ specify whats connected. The program could validate the choice with the XML for the FPGA config

Yes I agree.
live interrogation can only go so far towards 'auto' configuration.

I think an interrogation before , could narrow user choices. If we did it right we could do either way (interrogation or manually)

Another thing that needs to change is the one to one of the GUI combobox names and the mesa pinnames.

Currently that is how I keep track of what combo box is what mesa pin, but it is limiting as In this model I must have every pin possible prebuilt in the GUI.
(and I don't - this is the reason only only serial port is supported)
It would be better to dynamically add them, right now I dynamically add the information to the combobox and hide the unneeded comboboxes.
I should also add the meta data to the GUI, as I spend a lot of time moving data from/to the GUI

As for the replacement for the druid widget, I was considering using a notebook widget to fake idea of the druid widget.
The notebook is always going to be available.

Chris M

Is there documentation somewhere on the component that controls analogoutX, analogoutX-scalemax etc? (Like the documentation on hm2 encoders , for example.)

HAL question 1: what happens with unconnected/"floating" input pins?

HAL question 2: is it OK to have both bidirectional and out pins in the same net? I guess "no" since the out pin will be unhappy when driven by a bidir pin?


Edit: Now it actually does something useful: one can create axes (by editing code) and add some components, and it will create param init and nets. Just run ./pncconf2.py and it will generate a pncconf-test.hal file (not complete though).

Edit the get_axes() method in pncconf2.py to add or remove axes. To look at what's required to add support for a new card, look in halcomp/mesa/FPGAs.py (the M5I25 class) and in halcomp/mesa/daughtercards.py (M7I76, M7I77). (But the card part will probably change a lot - enumeration of compatible cards etc is not implemented yet.)

The sserial manual (I think only in master) has some information on the scalemax, minlim, maxlim parameters that set the scaling and limits on HAL 'in' numeric type sserial pins.

Unfortunately the manual refers to specific sserial cards while the treatment of sserial pins is the same regardless of the daughtercard type. Treatment of pins depends only on the data type of the pin. Sserial devices have 9 data types but only 4 are currently used for process (real time) data : signed, unsigned, stream, and count. Signed (like analogoutx) and unsigned sserial data outputs show up as float 'in' HAL pins with the above mentioned scaling parameters.

Ok. That brings me to

HAL question 3 (pin naming conventions):
Usually, we have HAL pin names like card.N.component.N.pin-name (where component.N can be nested, i.e. a "component" can be a 7i77 card or the like). Is that correctly understood?

With the SSerial cards, we have names like hm2_5i25.0.7i77.0.1.analogout1. Here hm2_5i25.0 is the first 5I25 card, 7i77.0 is the first 7I77 card connected to that 5I25 card, 1 is the SSerial "component" (?), and the SSerial component has got pins like
Is that correct? Does this mean that there are no "rules" on how HAL pin names are created and what they mean? (I had expenced the above to be called hm2_5i25.0.7i77.0.sser.1.analogout.01.pin-name or something similar.)

Also, say we have two 5I25 cards and each of them has one 7I77 card connected. Is the name of the second 7I77 card hm2_5i25.1.7i77.0 or hm2_5i25.1.7i77.1?

hm2_5i25.0.7i77.0.1.analogout3

hm2_5i25.0: 5I25 card 0
7i77.0.1: 7I77 on sserial interface 0 channel 1
analogout3: signal name

If it been commited, master has an alternate (and optional) sserial
device naming scheme that uses the sserial device serial number instead
of the pathname so instead of hm2_5i25.0.7i77.0.1.analogout3,
you would have: 7i77.serialnumber.analogout3, Where serialnumber is the individual serial number of the sserial remote. This has the advantage
that systems with multiple sserial devices can freely move them from
channel to channel without any change in the HAL file.

If I connect a 7I73 to the 7I77 sserial interface, would the components on that card then be called hm2_5i25.0.7i77.1.x.pin-name? I.e. there is really no "7i77", but rather an "sserial"?

I was under the impression that sserial boards could be daisy-chained, but now when I look I cannot find any cards with both sserial input and output(s)...?

The expansion sserial connection on a 7I77 (on 5I25 P3) is sserial channel 2
(field I/O is channel 0, analog out is channel 1 and the expansion connector is channel2 )
This sserial channel is just a feed through so is connected to the 5I25:

Here are some pins of a 7I73 connected to a 7I77:

10 float OUT 0.03882353 hm2_5i25.0.7i73.0.2.analogin1
10 float OUT 0 hm2_5i25.0.7i73.0.2.analogin2
10 float OUT 0.02588235 hm2_5i25.0.7i73.0.2.analogin3
10 u32 IN 0x00000000 hm2_5i25.0.7i73.0.2.display
10 s32 OUT 0 hm2_5i25.0.7i73.0.2.enc0
10 s32 OUT 0 hm2_5i25.0.7i73.0.2.enc1
10 s32 OUT 0 hm2_5i25.0.7i73.0.2.enc2
10 s32 OUT -1 hm2_5i25.0.7i73.0.2.enc3
10 bit OUT FALSE hm2_5i25.0.7i73.0.2.input-00
10 bit OUT TRUE hm2_5i25.0.7i73.0.2.input-00-not
10 bit OUT FALSE hm2_5i25.0.7i73.0.2.input-01
10 bit OUT TRUE hm2_5i25.0.7i73.0.2.input-01-not
...