Recommendation for testing... draft...

[Anonymous]

Trying to create a suggestion for a procedure to test new devices...

Is there a way to save a NAMED log file?
I tried some combinations but the name of the file did not change...

Regards,
Valter

[Anonymous]

Hi.
About the LOG file name, choosed by the user...
Looking the "op.c" source code, it seems that the line 351 is "overwriting" the value choosed by the user...

I don't know if there is any other implication, but, placing the following lines around it allows me choose a LOG FILE NAME...

if (saveLog) {
    // user invoke switch to save log file
    printf("--------------------------\n");
    if (strlen(LogFileName) == 0) {
        // no log file name was declared by the user, saving as "Log.txt" 
        printf("The LOG file name will be: Log.txt\n"); 
        strncpy(LogFileName, strings[S_LogFile], sizeof(LogFileName));  //v0.11.0 line 351
    } else {
        // user choosed log file name
        printf("The LOG file name will be: "); 
        printf("%s\n",LogFileName);
    }
    printf("--------------------------\n");     
} else {
    // log file is not invoked, BUT...
    // the old line 351, just in the case it is needed here...
    strncpy(LogFileName, strings[S_LogFile], sizeof(LogFileName));  //v0.11.0 line 351
}

Please take a look at it.
Regards,
Valter

[Anonymous]

Refers to the v0.11.0

Valter

[Alberto Maccioni]

No, as you can see the log file has a fixed name.
Regarding the procedure, I use a standard hex file without meaning, that puts data at the boundaries of all used sizes, so it's the same for all devices of the same family (12F, 16F, 18F, etc.)
Since writes are followed by verification, there is no need to re-read the device, unless in case of particular problems.

[Anonymous]

Hi.
Thanks for the reply.

[Recommendation for test]
Sorry for the suggestion, I did it because a "blink LED" is more or less considered the "helloworld" for MCUs...
I use and like it because it gives the users/me a visual indication that the first try succeed or not, so I suggested to transform such first contact into a sort of standard way to test the new/untested devices...
In a sense, this blink-led has already being done, it is sitting somewhere on the disk...

Perhaps, suggesting the method that you use, on the section about "contribution", will stimulate people to help test more untested devices...

[Log file with name]
Sorry also for posing the issue, I did not know that the fix log name was on purpose, looking at the help my first impression was that it was a working feature...
In my particular case, saving the log and having the ability to choose a specific name is important.
Yes, the write function verify/check for errors, which assures the correct values...
My need is to have a written record of the process and the files used to perform the flashing procedure for all the individual MCU that will be flashed. It will became part of documentation for that particular device.
In this case (my), instead of declaring that it was "done right", there is a need to record data about the procedure, showing as much as possible, "how" it was done, so this documentation will be part of the flashing process itself and the ability to save it with a choosen name will help a lot...
In this case (my), the docs (log, etc) will not assure the flashed values, instead, it will assure that the correct flashing procedure was done, and since the writing function itself checks for errors, it then, assures that the flashing device was received the planned procedure...

[conclusion]
Of course, no open source project should ask/demand that users follows testing procedures, but, just recommending (the word recommendation here is key) them, in my point of view, can help users to help/contribute with the project... since it is a relative task...

But if you think that it is unnecessary, no problem, it was just an suggestion that happens to me I decide to share the idea...

Regards,
Valter

[Alberto Maccioni]

I have to partially correct my earlier message, sorry.
The command line application "op" indeed has the option to change the log file name; the syntax is a bit odd (thanks to the getopt standard library):
-log=filename
Istead the GUI uses a fixed name.
Regarding verification, for me it's not practical to use the blink led method, as I would have to compile it for nearly every different device, and I have lots of them.
Also such small program would not fill the memory, and I had sometimes bugs in that region; in addition, simple small programs do not use all config words nor ID words.
Here a couple of files I use to verify different architectures.
To be honest a complete formal verification would require a lot of different combinations: memory filled from 0, to the end, with holes, aligned and not to boundaries, code protection, ID, backup config, EEPROM, hex with back jumps, etc.
At the beginning I tried a lot of combinations to spot all possible bugs; now I feel confident to just have one file per device/family.
Usually some errors are reported in writing config words; this is expected, since every device has different fixed bits that cannot be reset; a quick look at the datasheet can tell if the result is ok.
But sure it's a good idea to provide a clear verification procedure.
So in the end I would advise to write the reference verification hex file and save the log file.

[Anonymous]

Hi, thanks for the elaboration.
Please, consider inserting some "recommendation for testing" there on the section about contribution...
It is, ALSO, a good way to tell the users that developing/testing/keeping things running is NOT, an easy thing to do for long period of time, so inviting them to share the benefits and, at least a liitle bit of help...
Help which, in my oppinion is fair to ask...

As for the kind of help(testing) that can be asked, I think that as a general rule, projects will only be able to ask for simple stuff, otherwise people will tend not to cooperate...

So, perhaps issuing some lines about such "easy test recommendation" can help...

As part of technical doc, on the other hand, describing more details for more consistent and wide in scope tests can help, in the case some user start to dive into the code and is motivated to collaborate...

[Good Job]
It is CLEAR and EVIDENT that you have, for so long, done a huge ammount of job: code, diagrams, code comments, hardware, diagrams, explanations, etc, etc...
So, when I ask/suggest something, I know what kind of "territory" it will go into, because every little new thing may translate into LOTs of things to do...
In that sense, because of the stage OP is today, any thing or suggestion can only be considered to action if it is really worth doing...

So, when you have some time digging into the main doc (webpage), put some few lines there suggesting people to help test, with some indication how you are currently doing it (tests), and how people can possible help with this subject...

Keep the good job,
regards,
Valter