Please add info for humans to the .cfg file content.

[Dany]

Hi, currently the .cfg file of a project looks like below shown. As you can see there is no indication about the meaning of the settings.
It would be very nice if with each <VAL> also the actual settings represented by it would be shown, like in the ".cfgsch" (schemes) files.

Thanks in advance!

Extract from config file (.cfg):

<?xml version="1.0"?>
<MCU_DEVICE_FLAGS>
<DEVICE>
<DEVICE_NAME>P18F2550</DEVICE_NAME>
<VALUE>
<COUNT>12</COUNT>
<VALUE0>
<VAL>$300000:$0024</VAL>
</VALUE0>
<VALUE1>
<VAL>$300001:$000E</VAL>
</VALUE1>
<VALUE2>
<VAL>$300002:$003F</VAL>
</VALUE2>
<VALUE3>
<VAL>$300003:$001E</VAL>
...

Extract from a "scheme" file (.cfgsch): the "Names"and "descriptions" are present.

<DEVICE_NAME>P18F2620</DEVICE_NAME>
<SETTINGS>
<COUNT>34</COUNT>
<SETTING0>
<NAME>Oscillator Selection</NAME>
<DESCRIPTION>HS oscillator, PLL enabled (Clock Frequency = 4 x FOSC1)</DESCRIPTION>
</SETTING0>
<SETTING1>
<NAME>Fail-Safe Clock Monitor</NAME>
<DESCRIPTION>Disabled</DESCRIPTION>
</SETTING1>
<SETTING2>
<NAME>Int/Ext Oscillator Switchover</NAME>
<DESCRIPTION>Disabled</DESCRIPTION>
</SETTING2>
...

[janni]

There's indeed no reason why both kinds of configuration files should differ. Note however, that older cfgsch files became unusable after a change in cofig bits naming in mlk files .
No one would like that to happen to projects' configuration at some future moment. The way the configuration files are coded and read should change first, making it independent of config bits' description. Naturally, backward compatibility (or a way to convert older files) should be ensured.

[Dany]

There's indeed no reason why both kinds of configuration files should differ. Note however, that older cfgsch files became unusable after a change in cofig bits naming in mlk files .
No one would like that to happen to projects' configuration at some future moment. The way the configuration files are coded and read should change first, making it independent of config bits' description. Naturally, backward compatibility (or a way to convert older files) should be ensured.

Thanks Janni. I agree with you. That was indeed a problem with the older cfg files.
The way .cfg file are now, no problems are to be expected for the future I think: only the config word addresses and their values are defined.
What I ask is not to change what is there now, only to add some <...> fields for human reading, which are not used by the compiler/linker.

[janni]

And then make the cfgsch files identically formatted as they serve exactly the same function, just disconnected from any specific project. (Actually, there's no need for separate cfgsch files - all that is needed is a possibility to import configuration from other project, or export configuration as a template - modified cfg files could be used for both.)

[Dany]

And then make the cfgsch files identically formatted as they serve exactly the same function, just disconnected from any specific project. (Actually, there's no need for separate cfgsch files - all that is needed is a possibility to import configuration from other project, or export configuration as a template - modified cfg files could be used for both.)

Good idea!