PnCConf rework

I see. I'm getting the connection between the info in the .pin files and the HAL names now.

Then a 7I77 on 5I25 P2 would create pins like?

And the "7i77" and "7i73" parts of the names are really a convenience rather than something that differ between pins (i.e., there could never simultaneously be pin names that differ only in that part)?

Can you give an example of when the interface would not be 0?

Yes those look right for a 7i77x2 config, 7I77 on P2, though the pin file or xml file are the authoritative source on which sserial port is connected where

And yes, you could remove the remote name and not have a naming collision, at the expense of readability of course.

Sserial interfaces only support 8 devices per port, so if more than 8 are used you would have sserial port 0 plus sserial port 1 and beyond (to 4 maximum = 32 sserial channels possible)

The 5I25 7I77_7I74 config is a example of a config that has 2 sserial ports (and 11 channels)
The 7I80DB has a 7I74X4 config with all 32 (0.0 through 3.7) sserial channels used

andypugh wrote:

linuxcnc.org/docs/html/hal/general_ref.html

Thanks! Although even that document is not consistent - it links to a "Canonical Device Interface" description, which uses underscores in the names of pins (which breaks the first clause of the general naming conventions)...

Another question for Peter:

Looking at the available firmware PIN files (at /usr/share/doc/hostmot2-firmware-*/) I can't seem to find any (for the 50-pin connector cards) that supports more than 6x Encoder (muxed) per port. But the 7I65 supports 8 Encoders on one 50-pin port. Clearly I'm missing something, but what?

Edit: Another question: Are DAC outputs and ADC inputs done via SSerial? (What are their hal names?) - Edit2: but this also seems incompatible with the available firmwares...?

There are _many_ more configs than those in the LInuxCNC repository
(there are close to 200 pinout files)

freeby.mesanet.com/7i65x2.pin is an example 7I65 pinout file

I think an important bit of factoring that would simplify things
is not to worry about individual FPGA configurations as there are
potentially thousands, but rather the per connector daughtercards
that are supported (this is a much smaller number)

DAC outputs and ADC inputs can be done via sserial, SPI,
and local PWM (DACS only)

PCW wrote:

There are _many_ more configs than those in the LInuxCNC repository
(there are close to 200 pinout files)

f
I think an important bit of factoring that would simplify things
is not to worry about individual FPGA configurations as there are
potentially thousands, but rather the per connector daughtercards
that are supported (this is a much smaller number)

PNCconf does not concentrate on individual FPGA configurations, (other then a couple work arounds and to auto select some internal sserial descriptions of daughter boards as the XML does not differentiate between regular sserial channels and the ones needed for a specific daughter board. )

In PNCconf the daugther boards are handled separately and are hardcoded.
There is no XML file for daughter boards so I had to do this. In fact they are hardcoded with only one mode.
The biggest problem there is having to adjust the GUI component numbers to the daughter board's pin component numbers.

and of course the make_pinname method does lots of daughter board pin name conversion - but at least it's in one place.

Currently PNCconf reads the XML file and builds a data structure ( mesafirmwaredata ) with as much meta data as possible.
(There is also hardcoded example data in this array - as this is the old way PNCconf worked before XML files)

A couple of problem with this is :
1) Peters XML files and linuxcnc's are a little different, I recently added hacks to try to bridge this.
2) The XML files do not give some necessary data such as what daughter board can be used or what sserial's will be used for the daughter board.
3) some of the data must be gleamed such as if an encoder has 2,3 or 4 pins
4) some things like mux encoders need work arounds eg 7i77_7i76 needs the mux encoder faked into a regular encoder for PNCconf to display it properly as PNCconf assumes mux encoders are actually 2 encoders .
5) there is no way to know any rules of how to deselect components to release components for GPIO - sserial is much worse for this - it's not going to be clear to a new user how this works - I did a work around for this by building a 'fake' firmware name, 7i77x1 and auto deselecting things.

Serial data is kept in mesadaughterboarddata
It's much easier as it can't be changed by the user other then selecting different modes which currently is not available.
It's hard coded so as long as Peter doesn't change the daughter boards significantly all is good.

Chris M

Ok, so here's my idea so far:

* User's perspective: The user really only wants to set up a hierarchy of cards ("I have a 5I25 and to its P3 connector I have connected a 7I77.") and then to use the components (encoders, analogouts etc) supplied by those cards to control his/her machine ("Use 5I25.P3->7I77.TB3-ENC0 as X axis feedback, use 5I25.P2->7I76.TB2-STEPDIR3 as X axis control", etc). The user is not interested in FPGA pinouts, sserial channel numbers, or even HAL pin names (although the latter could be educational to display).

* PnCConf's perspective: We need to know the HAL pin names for each available component to be able to generate a .hal file. For some FPGA cards we need to know the firmware file name to be used (so we can supply it to the hm2_pci config parameter).


So the config process I had in mind is:

1) Let the user build up a hierarchy of cards. The available selections are limited only be the connectors (i.e. a 7I77 only fits a FPGA 25-pin IO; remote serial IO boards only fit SSerial outputs, etc). (Here we might want to display a note stating that the chosen layout must be supported by a firmware file or something like that.)

2) For each (FPGA) card that has been selected that requires specification of a firmware file, let the user select a file (using a File Open dialog). Note that we don't care about the firmware at all, except for its file name.

3) Let the user add and configure machine axes. We know about the components supplied by each daughter board (the number of feedback, control, input and output components and their TBx header names and top-level HAL pin names), and we display them accordingly. For example, we could have a "Feedback" drop-down list displaying all available feedback devices for the user to chose from for the current axis.

Now, under two assumptions, we already have everything we need to write out a complete HAL config:

a) The order of the FPGA card connectors does not change between firmwares. With this I mean that components (and SSerial channels) are always distributed among the connectors in the same order: on a 5I25, each component type are given lower numbers on P3 than the same type on P2; on a 5I22, components on P2 are always lower numbered than the same type on P3, P3 comps have lower index/number than those on P4; on a 3X20 components are always numbered from P4 to P5 to P9 to P8 etc... I hope this is the case?

b) All unused connectors have higher order than the used ones (i.e. there are never a situation where a user hooks up a 5I25's P2 but not the P3).

b of course is a weak assumption, but we can easily check for each configuration if it holds. If not, we can ask the user what kind of daughter board is supported with the selected firmware on each connector for which it doesn't hold.


Now, since we know what kind of components are supported by each daughter card, and their number; and since we know if the components are hooked up directly or through SSerial or something else, we can keep track of the start index for each component type on each card. And I think that's all that's needed to figure out the correct HAL pin names.

I believe this is something like what Peter suggested (worry about "the per connector daughtercards that are supported"), but perhaps taken a step further.

some notes:

1. On xml files, its problematical to use text string as keys if they do not come from a common source.
if xml files are to be used they should retain the original IDROM keys with the text as a convenience.
Heck better still would be just the bare IDROM since it can be unambiguously parsed into a set of
HAL pins (sserial devices excepted) when the quantity of each type of module is selected.
for off line parsing, It would be nice if the hm2 parsing code could be abstracted from the driver (I think Michael G is working on this: libhm2)

2. In any case the user _must_ specify which daughter cards are used on which connectors
A hint would be helpful for user input validation

3,4 these go away with live probing or using the drivers parsing scheme (and hm2 number of module specifications), that is the hm2driver driver has no problem doing this at all.

For 5 doing what the driver does (or better still live probing) works fine