xml files

This may indicate a major mis-understanding of how pncconf works
but that never stopped me from making suggestions before...

Is there any reason that pncconf could not use a XML file generated by
halrun show pin and halrun show parameter (perhaps with a XML output option added to HALRUN)
rather than a pinout created xml file.This would be less Mesa centric and work with any kind of config

Or perhaps a live version of pncconf that first lets you instantiate components (either comps or hardware)
and works with the now visible HAL pins/parameters. This would have the advantage of not needed a multiplicity of xml files and reflecting exactly what a user has in their setup (and works with SSERIAL peripherals and modes without restriction)

BTW thanks for all your work on pncconf!

I always like to discuss suggestions and new ideas!

PNCconf does care how the XML file is made, internally PNCconf actually converts it to a data array of it's own.

The problems I see with using (exclusively) HALRUN created XML or live probed systems. are:

- Impossible for me to test if I don't have the hardware - and there is lots of hardware!
- Can only configure hardware you have on hand at the moment, not the biggest hurdle but inconvenient and does not allow users to see what other hardware may be better suited or available
- most importantly, since to the only way to get HALRUN to create pin info is to select the firmware and number of each component, the user must know a fair amount about what he wants and how to get it before hand. i personally think that discover-ability of PNCconf's pin , component and signal selection is one of the best features of it. They can select a firmware name, even if they don't know anything about it, and see exactly the options possible with out having to know _anything_ about HAL or HALRUN or how to properly connect the hardware.
Now having PNCcong probe sserial daughter cards seems an ok halfway measure - so far they have much less options for users to choose from.

Why is having pre-generated XML files a bad idea, other then we need to find a convenient way to do it?

Chris M

"- Impossible for me to test if I don't have the hardware - and there is lots of hardware!"

Well if written generically enough, it should work with _any_ hardware even a new card with totally new signal names

"Why is having pre-generated XML files a bad idea, other then we need to find a convenient way to do it?"

Just that having data in two places that may possibly get out of sync seems fragile. live probing will always have the correct signal names

So maybe its not the best solution for all but consider that it would even allow pncconf to work on hardware/component combinations that only 1 user has (say Parallel + Pico +PIC +BLDC etc)

With_any_hardware is not really practical I think. There is more to PNCconf then just figuring out the pin names.
If new hardware has new components then PNCconf needs updates anyways. For instance PNCconf knew nothing of how to connect resolvers or sserial spindle control even when it knew the actual pin names.

Same with Pico or BLDC. pin names are only a small part of it.

Well yes and no, consider that GPIO can be connected pretty much anyway you want. Say that there was a hint about how things are connected ( PID output target, PID feedback source for example) then a utility could chose the hint(0) or hint(1) connection options for setting up PID regardless of the signal names. Just seems like there should be something between
a hardwired built into the program connection scheme and a connect anything to anything scheme.

BTW Sebastian Kuzminsky has started a buildbot for hm2 firmware that may make the problem with xml files for new firmware go away

well for instance _main board_ GPIO can be changed from input to output to open drain output but sserial can't be changed.
PNCcong would have to know this before hand ( which it does now)

sserial spindle control and PWM spindle control both can control a spindle drive but require different connections and parameters.
PNCconf needs to know the difference and asked for the needed parameter data in the GUI.

At the moment I can't see how to get around this, HAL is very flexible - sometimes too flexible

Yes I saw that Seb had a working buidbot. for firmware - I think this will work well.
I see sometimes you don't give the PIN file when suppling custom firmware ? Is there a reason for this?

PS just a reminder I am hoping for a print out of the pins for 5i25/7i77 combo the PIN file would be very helpful too. Thanks.

Actually the information about GPIO would be in a dynamically create XML file, that is the pin modifiers are in the parameters (the I/O / open drain options are all parameters for each GPIO but SSERIAL I/O have no such parameters). The information missing is the hint that says what they are.

But what I meant about GPIO is that for example just as pncconf should allow any user selected GPIO pin to be used for X+limit for example, it could also allow a user selected pin to connect to a PID comps output (but a hint would limit or order the choices to the most reasonable)

Part of my un-easyness about the static xml file representing what is in the FPGA is that it is somewhat contrary to one of the major design goals of Hostmot2 which is to have all information needed by the driver and ancillary programs reside in the FPGA itself, so there is no chance of version or phase errors
and no need to track (what could easily become 1000s) of ancillary data files that duplicate what is already available in the FPGA itself.

I no longer have access to the 7I77 proto but will have production cards this month

I dont always have pinout files because it takes a little work to make them though they should be available for any formally available firmware. They take a little work as they are generated live from the FPGA which means I need to physically install a card in a test machine and run a utility. This is not something that the XML file created during the firmware build can really replace as this constitutes part of the checking procedure of new firmware.