MX47x/37x PPS pin in multiple input groups

[lstandage]

The MX47x/37x PPS mapping has an interesting pin, RPB2. It appears in two different input groups in the data sheet (and internal documents), and thus it can be used by several more peripherals (with a different value) than currently supported.

For the inputs in Group C, RPB2 can be used by assigned 0b1111, whereas the inputs in Group D use the value 0b0111.

Currently, the problem is that anything in the core that is built for this part family gets a compile error, because _PPS_RPB2 gets multiple definitions:

#define _PPS_RPB2 (15 + _PPS_SET_C)
...
#define _PPS_RPB2 ( 7 + _PPS_SET_D)

I'm not sure how this is going to be fixed, other than avoiding the use of pin names in the #defines.

[EmbeddedMan]

@majenkotech Yeah, this is going to be tough. I think we'll need to somehow update the PPS support in the core to allow a single pin to somehow have multiple groups. I guarantee you that if Microchip did this for one part, it will be on other as well in the future.

[majenkotech]

Hmmm... I have used the MX470 and MX370 in projects and didn't notice this. Or maybe I did notice it and thought "I won't bother with that now, I'll just leave that definition off"...?

But yes, I think this would mean a bit of a massive change to the core.

The problem isn't multiple groups - we have that support already:

#define _PPS_RPF2       (15 + _PPS_SET_A |  _PPS_SET_B | _PPS_SET_D)

The problem is incorporating the "15" with the group so you can have something like:

#define _PPS_RPB2 (15 + _PPS_SET_C | 7 + _PPS_SET_D)

Obviously that's completely incorrect like that, but maybe a macro based system may work:

#define _PPS_RPB2 (_PPS_SET_C(15) | _PPS_SET_D(7))

We could maybe use a 32-bit word for the definition and have the lower 6 nibbles as the number for each group, and the upper 8 bits as the groups the pin belongs to. So you would have, for that definition,

..FEDCBA   F    E    D    C    B    A
00001100 0000 0000 0111 1111 0000 0000

Yes, I know there is only 4 groups (A-D), but we have the space in there for more, so why not future-proof it with two extras slots?

Another alternative is to just assume that "0000" is "not part of set" and then you have room for 8 sets (or 4 in a 16-bit type):

  D    C    B    A
0111 1111 0000 0000

Personally I'd prefer the first method - it is more robust and the second method may have problems with "unsetting" a PPS definition back to GPIO.

[majenkotech]

I notice we just have two definitions at the moment - one overriding the other:

pingroups_37x47x.h:#define _PPS_RPB2       (15 + _PPS_SET_C)
pingroups_37x47x.h:#define _PPS_RPB2       ( 7 + _PPS_SET_D)

So the set C will be unavailable but the set D will work.