Suggestion: provide an alternative boards-hv.txt file

[technoblogy]

Currently you have to locate and uncomment some 20 lines in the boards.txt file to activate the UPDI/Reset Pin Function menu option on the Tools menu.

As HV programmers are becoming available, more people will need these options. How about including an alternative version of the boards.txt file, called boards-hv.txt, which has the lines already commented out? Someone then just has to rename boards.txt to boards-old.txt, and boards-hv.txt to boards.txt, with no risk of accidentally messing something up.

Also, how about making DxCore consistent, with the HV options commented out by default?

[SpenceKonde]

HV UPDI tools are still extremely rare, especially now that there are two kinds of them (one for DD, and one for tiny, so I'm uncofortable doing that at this oime

I don't believe there is a way for the core author to grey out menu option; do you know of a way?

[technoblogy]

I don't believe there is a way for the core author to grey out menu option; do you know of a way?

That would be nice, but I've searched for this and can't find one (and I don't recall ever seeing a core with a grayed-out menu option).

My alternative suggestion is to comment out the menu entry:

#menu.resetpin=UPDI/Reset Pin Function (burn bootloader req'd)

and leave the other 20 entries uncommented. Someone then only has to uncomment one line. I've tested this and it works.

[SpenceKonde]

Uh.... I didn't think that worked, I thought it kept the IDE from starting or kept the boards from showing because they had an illegal menu name...

DxCore is also very different because the RESET pin can be set as input or reset and it has no impact on programming, so the reset pin menuis always there. Also the HV options are always present for optiboot,butnot for non-optiboot. Because optiboot users may be willing to accept loss of UPDI programming even without an hv programmer since they have optiboot.

[technoblogy]

Uh.... I didn't think that worked

I'm pretty sure it worked. I'll test it again to make sure.

DxCore is also very different …

OK, I understand - fair enough.

[SpenceKonde]

As I reread my response I realize I wasn't clear about one bit - the options that require HV programming after setting are always available for optiboot boards on both cores, not just DxCore.

So the options we expose are: No reset pin (all parts) Alt reset pin on tinyAVRs with >20 pins (works on 2-series only) PA0 as Reset on Optiboot boards only. PA0 as GPIO on optiboot boards only.

DxCore: Reset as Reset, and Reset as Input on all parts No options for the UPDI pin on DD without optiboot UPDI as GPIO and UPDI as UPDI on DD with optiboot.

Note that when using PA0 as GPIO on tinyAVR, it is an AWFUL output. The drive strength is closer to that of the pullup than a normal output pin drive - Even running at 5v, just half a milliamp of current will induce a 1v voltage drop (ie, V_OL = 1V @ 0.5mA when sinking current and V_OH = 4V (1V below Vdd) @ 0.5V when sourcing current. A normal I/O pin sinking current under identical conditions would have V_OL = 25mV or so, and V_OHof around 4.96V, or 40mV below Vdd.

Oh interesting!!! Yeah there is actually another issue with this on the AVR DD parts. DxCore sets almost every fuse on an upload via UPDI, even the one that controls reset and updi pins. We block updi uploads on optiboot definitions (because the result of uploading in that way is guaranteed not to work). Since the only configuration where there's a menu option that breaks the chip doesn't allow uploads via UPDI, there is never a risk of an "upload" bricking the chip. So enabling that would require either removing configuration of EESAVE and Reset pin configuration on upload for all parts, or else violating one of the core design principles of all of my cores, which is that upload must be incapable of breaking the chip.

[technoblogy]

Hi Spence,

As I reread my response I realize I wasn't clear about one bit - the options that require HV programming after setting are always available for optiboot boards on both cores, not just DxCore.

OK, got that.

Note that when using PA0 as GPIO on tinyAVR, it is an AWFUL output. The drive strength is closer to that of the pullup than a normal output pin drive - Even running at 5v, just half a milliamp of current will induce a 1v voltage drop (ie, VOL = 1V @ 0.5mA when sinking current and VOH = 4V (1V below Vdd) @ 0.5V when sourcing current.

Yes, I see that now. I didn’t read the datasheet carefully enough the first time.

Thanks, David

[SpenceKonde]

I don't think this is worth providing - if you want to PR it, go ahead, I'll merge it, but it's not worth going over all my boards and cores for this.