Rework fuse handling? about pdk-includes HOT 4 CLOSED

Apparently my assumption was wrong: "code option" != "easy pdk fuse" and all other code options are configured in other, undocumented registers.

The point about PDK_SET_FUSE(); not using the factory defaults still stands though.

from pdk-includes.

@cmfcmf - Because of the incorrect assumptions regarding FUSE vs. MISC2/MISC_LVR/ROP in your first post, it's a little hard to figure out what exactly you are proposing, but I'll try to respond to some of your concerns.

First, the concept of 'default' value is a little ambiguous...

One interpretation of default value, would be to use the default value as defined in the Padauk IDE's .INC source files. The potential problem with this is they disagree a bit with each other. For instance, the default value for the PFS173 would include Security Off, but the default value for PMS152 uses Security On. That would potentially be a bit confusing to have the behavior change from IC to IC. And, sometimes you would have to OR in an option, other times you would have to AND it in, which would get complex rapidly.

Another interpretation of default value, would be to use the value as comes pre-installed on a 'blank IC. Because of the way ROM works, this means that every bit that matters starts out as a 1, and would have to be programmed down to 0 as needed. So, AND would have to be used instead of OR for FUSE options. This is also a bit confusing as sometimes (depending on the IC) the 'unused' bits that are supposed to be low are a 1, and it is unclear what happens if they aren't actually programmed to a 0.

So, currently we are using a mask that sets all the required low bits to 0 properly, and leaves all the option bits at 0, unless turned on by OR'ing an option's value. This means we are more consistent from IC to IC. Maybe it would make more sense to invert things and instead AND in an option's value, but that seems less consistent to the way we usually set up registers (almost always done using OR).

Sometimes just using PDK_SET_FUSE() without passing anything in might give the correct defaults, but that doesn't seem like something that should be relied on. I would think best practice is to always define each and every option that matters when setting a FUSE value. We could actually change the definition of PDK_SET_FUSE to require each option to be set, but that might be a little too restrictive.

Perhaps @freepdk also wants to weigh in on why the fuse values are set the way they are?

from pdk-includes.

Thank you for your detailed explanation. 👍
Given that there doesn't seem to be the defition of what exactly should be the default value, I'm fine with leaving everything as is.

We could actually change the definition of PDK_SET_FUSE to require each option to be set, but that might be a little too restrictive.

That would mean something along the lines of PDK_SET_FUSE(FUSE_SECURITY_ON, FUSE_PB4_PB5_NORMAL, FUSE_BOOTUP_SLOW);, so that the user cannot forget one of the fuse settings, right?
The potential downside I'm seeing with this is that different µCs might be using a different number of fuses, therefore the PDK_SET_FUSE would potentially need to be defined per device.

from pdk-includes.

Thank you for your detailed explanation. 👍
Given that there doesn't seem to be the defition of what exactly should be the default value, I'm fine with leaving everything as is.

Ok, sounds good. Go ahead and close this issue if you are happy with things as they are.

We could actually change the definition of PDK_SET_FUSE to require each option to be set, but that might be a little too restrictive.

That would mean something along the lines of PDK_SET_FUSE(FUSE_SECURITY_ON, FUSE_PB4_PB5_NORMAL, FUSE_BOOTUP_SLOW);, so that the user cannot forget one of the fuse settings, right?

Yes, exactly. Again, not recommended, but that is an option.

The potential downside I'm seeing with this is that different µCs might be using a different number of fuses, therefore the PDK_SET_FUSE would potentially need to be defined per device.

I agree with the downside you mentioned.

Another potential downside would be less portable code. For instance, what if your program only cares about FUSE_SECURITY_OFF and FUSE_BOOTUP_FAST. With PDK_SET_FUSE the way it currently is, the same code could be used across most (if not all) µCs, and the other more specific fuse options would just get set to their 'defaults' (all 1s). Changing to the above more restrictive PDK_SET_FUSE option, would mean a lot of #ifdef lines making for really messy source code.

from pdk-includes.