I think the HAS_* macro names have a high risk of conflicting with user names (one can easily imagine a programmer choosing HAS_COMP or HAS_ADC for a macro referring to some feature in their software).
Maybe some kind of prefix could help?

I am just in the process of setting up a new project from scratch and am trying to use the most recent includes, which I intendend to clone into my path somewhere. (Before I was just lazy and reused old structures)

It turns out this is quite cumbersome due to the need to put the easy-pdk includes somewhere else. So my suggestion would be to clone or move them also into this repository?

Furthermore, the substructure of the later include path could be reproduced also in this repository. In the example these includes are in the subfolder "pdk", while this is not defined here.

PMS150G support?

Now that SDCC generates efficient code for assignment from an address that is just a cast integer literal to a __sfr, IMO the asm macros for factory clibration aren't needed anymore.
Inline asm tends to interfere with optimizations, so for larger functions containing a use of factory calibration values, the assignment is likely to result in more efficient code being generated by SDCC.

How we should deal with small differences between devices , or in another words difference between default periph/xxx and device ?
For example minus input of comparator, on PFS154 GPCC[3-1] '101' is PB7 but on PMS150C is PA7 . by default we have GPCC_COMP_MINUS_PB7 but on PMS150C should be GPCC_COMP_MINUS_PA7 for same value

Create another version of comparator.h ?
add overrides inside device/xxx.h
or maybe create another .h with overrides form default like

override_PMS150C.h

#undef GPCC_COMP_MINUS_PB7
#define GPCC_COMP_MINUS_PA7          (5 << GPCC_COMP_MINUS_BIT0)

I'm considering adding support for PFC161. For peripherals this should be straightforward; I can look up the register definitions in the datasheet, add them to the device-specific header and if necessary modify the common peripheral headers. But what about code options? Where do you find the values for those?

Also is there anything else to consider when adding support for a new device?

This repo need a clearly identified LICENSE so people know what can and cannot be done with it.

@freepdk, my preference for this is MIT, but these files have their roots from easy-pdk-programmer-software (even though they have been changed dramatically from what was/is there) which is GPL v3. Are you ok with (re-)licensing these include files as MIT?

I think the fuse handling as it is now is confusing. It currently works by OR-ing FUSE_RES_BITS_HIGH with the individual fuse settings. I'll further detail my thinking with the PFS173 as an example.

I would expect that calling PDK_SET_FUSE(); would use the factory default values (i.e., no security, strong PB4/PB5, fast bootup). However, it currently sets a mix of factory default and non-default values:

• non-default: security on, PB4/PB5 normal, bootup slow
• default: all other code options: lvr, interrupt src0/1, comparator, pwm source, tmx source

If we later add a #define for the currently missing code options (such as lvr, comparator, ...), we would also need to change FUSE_RES_BITS_HIGH. This, in turn, would change the behavior of calling PDK_SET_FUSE();!

I suggest to rework the fuse handling like this:

#define FUSE_RES_BITS_HIGH  0b111111111111111

#define FUSE_SECURITY_ON    0b111111111111110
#define FUSE_SECURITY_OFF   0b111111111111111
#define FUSE_PB4_PB5_NORMAL 0b111111011111111
#define FUSE_PB4_PB5_STRONG 0b111111111111111
#define FUSE_BOOTUP_SLOW    0b110011111111111
#define FUSE_BOOTUP_FAST    0b111111111111111

// ...

#define PDK_SET_FUSE(f) \
    __asm__( \
      ".area FUSE (ABS)                               \n" \
      ".org ("_STR(FUSE_WORD_ADDR)"*2)                \n" \
      ".word ("_STR(FUSE_RES_BITS_HIGH)"&"_STR(f)")   \n" \ 
      ".area CODE                                     \n" \
    )

The macro would now work as expected:

• PDK_SET_FUSE(); sets all to factory values, even if we later add definitions for more fuses
• PDK_SET_FUSE(FUSE_SECURITY_ON); enabled security, leaves all other values at factory default
• PDK_SET_FUSE(FUSE_SECURITY_ON & FUSE_PB4_PB5_NORMAL); enabled security and normal I/O, all bootup at factory default.

Note that you have to bitwise-and the fuse settings instead of bitwise-oring them. If we don't like that, we could also instead invert the fuse definitions:

#define FUSE_RES_BITS_HIGH  0b0111111111111111

#define FUSE_SECURITY_ON     0b000000000000001
#define FUSE_SECURITY_OFF    0b000000000000000
#define FUSE_PB4_PB5_NORMAL  0b000000100000000
#define FUSE_PB4_PB5_STRONG  0b000000000000000
#define FUSE_BOOTUP_SLOW     0b001100000000000
#define FUSE_BOOTUP_FAST     0b000000000000000

// ...

#define PDK_SET_FUSE(f) \
    __asm__( \
      ".area FUSE (ABS)                                    \n" \
      ".org ("_STR(FUSE_WORD_ADDR)"*2)                     \n" \
      ".word ("_STR(FUSE_RES_BITS_HIGH)" & ~("_STR(f)"))   \n" \ 
      ".area CODE                                          \n" \
    )

(I'm not entirely sure if that is how inline assembler works and if bitwise inverting 0b000000000000000 will lead 0b11111111 or 0b1111111111111111)

This would allow us to use PDK_SET_FUSE(FUSE_SECURITY_ON | FUSE_PB4_PB5_NORMAL);

There seems to be a discrepancy regarding what fuses are supported by the PFS154 between current information on the Free-PDK website, device headers, and currently published datasheet by Padauk.

The website asserts that the PFS154 does not support LVR fuse settings (instead using MISCLVR register), and the pfs154.h device header correspondingly does not include definitions for the LVR fuses. However, according to the datasheet available from Padauk (dated Mar 23, 2023) the PFS154 does feature LVR fuses.

The datasheet also contains no mention of a MISCLVR register.

Is the Free-PDK information incorrect, or has Padauk changed the PFS154?