Peripheral Pin Select and device files

[GoogleCodeExporter]

Hi Rob,

I'm currently working on PPS module, which allows to arbitrarily map function 
to remappable pins. This is a very nice feature, only available for recent PICs.

Searching PPSCON register, I've identified:
  - 39964B: J53 family
  - 39932D: J11 family
  - 39931D: J50 family
  - 39974A: J13 family

Using PPS is done 2 different ways whether the mapped function is an input or 
output. For input, the logic is assign a remappable pin number to a function.
Ex:    RPINR16_RX2DT2 = 9  -- assign pin RP9 to RX2 function (EUSART2)

For output, the logic is reversed, you assign a function to a pin number.
Ex:    RPOR10_RPOR = 6  -- assign TX2 function (which has the ID number 6) to 
remappable pin RP10

I'm currently writing a library to deal with PPS, I'm not sure far I can go 
with this, but I'd need to use aliases for output function, as a first step. 
Trouble is their ID values aren't normalized. Considering TX2 function:

  - J53: TX2 has n°6 (table 10-14, page 162)
  - J11: TX2 has n°5 (table 10-14, page 152)
  - J50: TX2 has n°5 (table 10-14, page 152)
  - J13: TX2 has n°6 (table 10-14, page 160)

I wad thinking these differences could be hidden in device files, which would 
actually declares these aliases:

const byte PPS_TX2_CK2 = 6 -- or 5, etc...

Does it make sense to you ? Do you see another way to do this ? Should I edit 
devicepsecific.json, and if so, can you provide some guidelines (format) ?

Cheers,
Seb

Original issue reported on code.google.com by sebastie...@gmail.com on 15 Apr 2011 at 1:44

[GoogleCodeExporter]

I'll have to do some homework before I can give a reasonable reply!
Rob.

Original comment by robhamerling on 15 Apr 2011 at 5:57

[GoogleCodeExporter]

As far as I can see, current four PIC family can be splitted in two types 
according to the way the declare their PPS output function ID numbers (eg. TX2 
= 5 or TX2 = 6). So I could basically deal with in pps.jal library, but in the 
near future, PPS could also be available on other PICs with different numbering 
as well.

Let me know, after your homework :) what make the most sense to you.

TIA
Seb

Original comment by sebastie...@gmail.com on 15 Apr 2011 at 6:58

[GoogleCodeExporter]

Apart from more mappable pins with the j13 and j53 the differences are only in 
the output numbering for TX2/CK2 and DT2. And there are currently only 2 
groups. So it looks to me that it would be most practical to add a PPS group 
indication in the device files and handle the differences between groups in the 
PPS library. This will have minimal impact on device files and maximum freedom 
for the implementation of the PPS 

Consequences for the device files generation:

1. define PPS groups in constants_jallib.jal, e.g.:
   const   PPS_0   = 0      -- device does not support pin mapping
   const   PPS_1   = 1      -- PPS group 1  18[L]FxxJ11, 18[L]FxxJ50
   const   PPS_2   = 2      -- PPS group 2  18[L]FxxJ13, 18[L}FxxJ53 

2. The dev2jal script has to add to the device files a statement like:
   const PPSGROUP = PPS_x   

3. Since the PPS-group cannot be derived from the MPLAB .dev files it will have 
to be added to devicespecific.json (similar to ADC group), to be handled by the 
dev2jal script.

Original comment by robhamerling on 17 Apr 2011 at 8:46

• Changed state: Accepted

[GoogleCodeExporter]

Hi Rob,

Your suggestion looks good to me, but since differences are minimal, I could 
still handle these in pps.jal library. I have concerns about a growing number 
of PPS groups, for now, only 2, but in the future there could be ~ as many 
group as devices, depending on how Microchip decides to deal with PPS functions.

To sum up: I can save you manual work and fully handle differences in pps.jal, 
as in ADC libraries. In the near future, if things are getting crowdy, we may 
reconsider this issue.

Cheers,
Seb

Original comment by sebastie...@gmail.com on 18 Apr 2011 at 10:04

[GoogleCodeExporter]

Adding a PPS group to the device files is pretty simple an not much work. In 
fact I was so confident about the idea that it is already partly in place in my 
local copy! Adding a PPS group for 40 PICs in devicespecific.json is a matter 
of copy and paste.  
I expect using PPS groups allows better (and less?) code in the PPS library: no 
checks on individual PIC-types but on group level (device independency is one 
of the goals with of our device files). 
And in my crystal ball I see not many more groups ....

Original comment by robhamerling on 18 Apr 2011 at 3:07

[GoogleCodeExporter]

OK, so I'm waiting for your commit !

Thanks
Seb

Original comment by sebastie...@gmail.com on 18 Apr 2011 at 3:10

[GoogleCodeExporter]

A constant PPS_GROUP is added to the device files.
The file devicefiles.html contains a section on PPS and groups.
Tools and support files are updated.  

Original comment by robhamerling on 18 Apr 2011 at 6:56

[GoogleCodeExporter]

I'm not sure if PPS_GROUP should reflect this too, but PPS output function 
registers seggregate differently. Ex: RPOR19_RPOR is in PPS_GROUP = 1 and 2, 
but only in 18F4XJYY devices (not 18F2XJYY). This means in pps.jal lib I need 
to split PPS groups into two sub-groups (ideally, I'd have prefered to treat 
one group as a whole).

In other words, PPS_GROUP is valid for input function only, and this is what 
was supposed to be at the beginning. I'll use "if defined" logic.

Original comment by sebastie...@gmail.com on 19 Apr 2011 at 1:49

[GoogleCodeExporter]

Ooops, PPS groups are valid for *output" functions IDs, not *input*. Anyway, 
that's just for the record.

Cheers,
Seb

Original comment by sebastie...@gmail.com on 19 Apr 2011 at 2:00

[GoogleCodeExporter]

As far as I understood the datasheets about this subject for input function 
mapping all PICS are equal: pin selection for a specific input function is 
controlled by the same register for all PICs. For example the pin for RX2DT2 is 
controlled by RPINR16_RXDT2. 
Even though there is no functional difference for input, 'bigger' PICs have 
generally more remappaple pins that smaller PICs. This difference is not 
covered by PPS grouping.

For output function mapping there are functional differences, as mentioned 
above, but also: bigger PICs have more functions to map.

The current PPS grouping is not fixed, when a different grouping or more 
refinement is required we can revise the design.

Original comment by robhamerling on 19 Apr 2011 at 6:00

[GoogleCodeExporter]

done as of rev.2588

Original comment by sebastie...@gmail.com on 20 Apr 2011 at 10:10

• Changed state: Fixed