pic32prog.conf file

[robert-rozee]

with the additions being made to allow a pic32prog.conf file for device configuration, will this mean that the single excutable pic32prog.exe (for win32) will no longer function standalone? or will the .conf file be optional and only contain configuration details for devices not already described in the C source code?

it is rather critical issue for me, as i've an article about to go into print with usage instructions (and direct links into GitHub) that assume only the file pic32prog.exe is required for programming the MX150/250, MX170/270, MX695/795 and MX470. if a .conf file becomes mandatory, then i will need to contact the publisher and make changes to the text before things go to print.

cheers,
rob :-)

[lstandage]

What if we did it as a hybrid approach? "Supported" devices would still be
hard coded and the stand alone would be sufficient. Then new devices could
be added to the conf file.

The main reason for this is because pic32prog is in the chipKIT core, and
those developers would like to be able to add new parts, especially if
they're on the early adapter list here at Microchip.

Thanks,
Larry

On Saturday, October 24, 2015, robert rozee [email protected]
wrote:

with the additions being made to allow a pic32prog.conf file for device
configuration, will this mean that the single excutable pic32prog.exe (for
win32) will no longer function standalone? or will the .conf file be
optional and only contain configuration details for devices not already
described in the C source code?

it is rather critical issue for me, as i've an article about to go into
print with usage instructions (and direct links into GitHub) that assume
only the file pic32prog.exe is required for programming the MX150/250,
MX170/270, MX695/795 and MX470. if a .conf file becomes mandatory, then i
will need to contact the publisher and make changes to the text before
things go to print.

cheers,
rob :-)

—
Reply to this email directly or view it on GitHub
#23.

Sent from an iMSAI 8080 over a 300 baud modem. ;-)

[robert-rozee]

i could see that approach working extremely well. although it may be prudent to handle what happens when a device exists BOTH internally as well as in the .conf file.

perhaps one mechanism would be to add an optional 'override' parameter to each processor entry in the .conf file: if 'override' is NOT specified the internal parameters (if they exist) will be used; if "override=1" is specified, then the data from the .conf file is used in preference to any internal data held for that specific processor.

cheers,
rob :-)