Thinking behind LVP = Off is that a user would probably have some sort of ICSP programmer, and that they would want access to as many IO pins as possible (hence internal oscillator, MCLR off and all A/D pins digital by default) This does assume the the LVP smart enough to override that fuse bit?
Your thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First off, color me a fan of HVP programming. And especially having the MCLR pin for input on low pincount device where it really counts.
I commend Microchip for having HVP/LVP ability in the Pickit 2 and Pickit 3 VS Atmel AVRISP MKII with only LVP. Just look at AVRFreaks forum for the "Pit of Misery" when someone accidently blows the RstDis fuse, yep, a bricked AVR, and now need a third party de-bricker or a Dragon and HVP to save it.
William rightly complains about the newer Microchip devlepment boards that only work with LVP programming? (don't have one). Is it possible for GCB to recognize these boards and insert LVP=ON to preclude bricking?
It is certaintly is a dilemna.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In anything like this, the question is how will it affect existing users? In particular, will existing programs stop functioning properly when they upgrade to a new version of the compiler?
Given that for years the default has been to let the LVP and MCLR pins act as IO, we can safely assume that many users have done so without thinking about it. If we change the default, their programs may lose access to the pins, or may not function at all, until they override the new default. That seems like the sort of nasty surprise that we ought to avoid in an upgrade.
So, I'd be very strongly against changing the default globally, but we do need a solution. Three thoughts on possible solutions:
1. We provide libraries for the offending development boards that are too stupid to protect themselves from bricking, and advise users that they should use libraries whenever available.
2. Provide a way for individual users to change the default for their installatin. I can easily add an option to gcbasic.ini to let this be toggled, but that could cause an issue if someone installs a new copy of the compiler and forgets to change the setting.
3. Provide a way to tell the compiler what programmer is being used, and have the default LVP setting as part of the programmer configuration. (Pretty much what Kent suggests above). I think this is a better option than (2) - we put the onus on whoever is setting up the programmer, not every user. It also means that the default only changes when it must be changed. The downside to this is that the IDE tools would need some tweaking to allow the compiler to call the programmer, rather than calling the compiler and then calling the programmer directly. To reduce the speed impact of this, I can add a command line parameter to the compiler to avoid a recompilation if the output hex file already exists and is newer than the input gcb file.
Another advantage of giving the compiler more control over the programmer and letting it know what programmer is in use is that we could also have the #option bootloader stuff added automatically by the compiler when needed.
Any other thoughts on how we can fix this without causing any nasty surprises?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Form the Quickstart Guide of the Microchip Curiosity HPC Board:
In the Option categories drop-down menu, select ProgramOptions; ensure that
the Enable Low Voltage Programming checkbox is checked (Figure 2-4). This
option should go default to checked, which ensures low-voltage programming.
Click the OK button. The Curiosity HPC Board is now ready to be programmed.
There is a similar paragraph in all 4 of the curiosity guides and the Xplorer.
I would say that Microchip sees LVP as the future, to the extent that the PKOB Programmers will not even see a device set to HVP.
If we set it to LVP by default it will work in all the latest development boards and with all the PICKit devices.
If, on the other hand, we set it to HVP by default the user would have to have a PICKit 3 to set it back before using one of the new generation of Development boards.
It would also mean that they get a one time program on a Curiosity board, as the raw PIC will be LVP and GCBASIC will flash it and set the HVP bit. Next time the user tries to program it the Curiosity board it will probably refuse because it is only a LVP programmer and the device is set for HVP.
I say lets leave sleeping dogs lay, no need to fix what is not broken.
Cheers
Chris
Last edit: Chris Roper 2017-11-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Settng as LVP = Off as the default.
Thinking behind LVP = Off is that a user would probably have some sort of ICSP programmer, and that they would want access to as many IO pins as possible (hence internal oscillator, MCLR off and all A/D pins digital by default) This does assume the the LVP smart enough to override that fuse bit?
Your thoughts?
First off, color me a fan of HVP programming. And especially having the MCLR pin for input on low pincount device where it really counts.
I commend Microchip for having HVP/LVP ability in the Pickit 2 and Pickit 3 VS Atmel AVRISP MKII with only LVP. Just look at AVRFreaks forum for the "Pit of Misery" when someone accidently blows the RstDis fuse, yep, a bricked AVR, and now need a third party de-bricker or a Dragon and HVP to save it.
William rightly complains about the newer Microchip devlepment boards that only work with LVP programming? (don't have one). Is it possible for GCB to recognize these boards and insert LVP=ON to preclude bricking?
It is certaintly is a dilemna.
In anything like this, the question is how will it affect existing users? In particular, will existing programs stop functioning properly when they upgrade to a new version of the compiler?
Given that for years the default has been to let the LVP and MCLR pins act as IO, we can safely assume that many users have done so without thinking about it. If we change the default, their programs may lose access to the pins, or may not function at all, until they override the new default. That seems like the sort of nasty surprise that we ought to avoid in an upgrade.
So, I'd be very strongly against changing the default globally, but we do need a solution. Three thoughts on possible solutions:
1. We provide libraries for the offending development boards that are too stupid to protect themselves from bricking, and advise users that they should use libraries whenever available.
2. Provide a way for individual users to change the default for their installatin. I can easily add an option to gcbasic.ini to let this be toggled, but that could cause an issue if someone installs a new copy of the compiler and forgets to change the setting.
3. Provide a way to tell the compiler what programmer is being used, and have the default LVP setting as part of the programmer configuration. (Pretty much what Kent suggests above). I think this is a better option than (2) - we put the onus on whoever is setting up the programmer, not every user. It also means that the default only changes when it must be changed. The downside to this is that the IDE tools would need some tweaking to allow the compiler to call the programmer, rather than calling the compiler and then calling the programmer directly. To reduce the speed impact of this, I can add a command line parameter to the compiler to avoid a recompilation if the output hex file already exists and is newer than the input gcb file.
Another advantage of giving the compiler more control over the programmer and letting it know what programmer is in use is that we could also have the #option bootloader stuff added automatically by the compiler when needed.
Any other thoughts on how we can fix this without causing any nasty surprises?
Form the Quickstart Guide of the Microchip Curiosity HPC Board:
There is a similar paragraph in all 4 of the curiosity guides and the Xplorer.
I would say that Microchip sees LVP as the future, to the extent that the PKOB Programmers will not even see a device set to HVP.
If we set it to LVP by default it will work in all the latest development boards and with all the PICKit devices.
If, on the other hand, we set it to HVP by default the user would have to have a PICKit 3 to set it back before using one of the new generation of Development boards.
It would also mean that they get a one time program on a Curiosity board, as the raw PIC will be LVP and GCBASIC will flash it and set the HVP bit. Next time the user tries to program it the Curiosity board it will probably refuse because it is only a LVP programmer and the device is set for HVP.
I say lets leave sleeping dogs lay, no need to fix what is not broken.
Cheers
Chris
Last edit: Chris Roper 2017-11-24