Problem defining PPS Tables, posible Bug/Oversight

Created Mon, 24 Jun 2013 15:53:28 +0000 by caroper

caroper

Mon, 24 Jun 2013 15:53:28 +0000

I have come across a potential problem in the way the PPS tables are handled.

The PIC32MX150F128B has a Pin RB12 that can be used as GPIO but it can not be used with PPS.

If the PPS tables in the Board_Data.c file are enumerated sequentially how do I define the entry for RB12 as it has no RPB designation.

I have entered it as PPB12 in the hope that it will be ignored as invalid but I have a nagging feeling it is going to throw out the rest of the enumeration process.

Should I rather just leave it out of the Table? If so how are the tables Dimensioned, is it according to #define NUM_DIGITAL_PINS ?

My Board definition files are attached to show the problem in context.

Any suggestions?

Cheers Chris

EmbeddedMan

Mon, 24 Jun 2013 18:26:58 +0000

Chris,

It should be possible. For example, in the Fubarino Mini Board_Data.c digital_pin_to_pps_out_PGM[] array looks like this:

const uint8_t digital_pin_to_pps_out_PGM[] = { _PPS_OUT(_PPS_RPB13R), // 0 RB13 NOT_PPS_PIN, // 1 RA10 NOT_PPS_PIN, // 2 RA7 _PPS_OUT(_PPS_RPB14R), // 3 RB14 _PPS_OUT(_PPS_RPB15R), // 4 RB15 _PPS_OUT(_PPS_RPA0R), // 5 RA0 _PPS_OUT(_PPS_RPA1R), // 6 RA1 _PPS_OUT(_PPS_RPB0R), // 7 RB0 _PPS_OUT(_PPS_RPB1R), // 8 RB1 _PPS_OUT(_PPS_RPB2R), // 9 RB2 _PPS_OUT(_PPS_RPB3R), // 10 RB3 _PPS_OUT(_PPS_RPC0R), // 11 RC0 _PPS_OUT(_PPS_RPC1R), // 12 RC1 _PPS_OUT(_PPS_RPC2R), // 13 RC2 _PPS_OUT(_PPS_RPA2R), // 14 RA2 _PPS_OUT(_PPS_RPA3R), // 15 RA3 _PPS_OUT(_PPS_RPA8R), // 16 RA8 _PPS_OUT(_PPS_RPB4R), // 17 RB4 _PPS_OUT(_PPS_RPA4R), // 18 RA4 _PPS_OUT(_PPS_RPA9R), // 19 RA9 _PPS_OUT(_PPS_RPC3R), // 20 RC3 _PPS_OUT(_PPS_RPC4R), // 21 RC4 _PPS_OUT(_PPS_RPC5R), // 22 RC5 _PPS_OUT(_PPS_RPB5R), // 23 RB5 _PPS_OUT(_PPS_RPB7R), // 24 RB7 _PPS_OUT(_PPS_RPB8R), // 25 RB8 _PPS_OUT(_PPS_RPB9R), // 26 RB9 _PPS_OUT(_PPS_RPC6R), // 27 RC6 _PPS_OUT(_PPS_RPC7R), // 28 RC7 _PPS_OUT(_PPS_RPC8R), // 29 RC8 _PPS_OUT(_PPS_RPC9R), // 30 RC9 _PPS_OUT(_PPS_RPB10), // 31 RB10 _PPS_OUT(_PPS_RPB11), // 32 RB11 };

You can see that pins 1 and 2 are not PPSable, and so are marked as such in this table.

Does that help?

*Brian

caroper

Mon, 24 Jun 2013 18:47:42 +0000

Chris, It should be possible. For example, in the Fubarino Mini Board_Data.c digital_pin_to_pps_out_PGM[] array looks like this: const uint8_t digital_pin_to_pps_out_PGM[] = { _PPS_OUT(_PPS_RPB13R), // 0 RB13 NOT_PPS_PIN, // 1 RA10 NOT_PPS_PIN, // 2 RA7 _PPS_OUT(_PPS_RPB14R), // 3 RB14 Does that help? *Brian

It helps a great deal thanks. I was working from the MX250 Definition from DP32 and trying to add back the 2 extra pins that are freed up by the lack of USB.

In that file there are no NOT_PPS_PIN so I overlooked the obvious. I will have a good look at the Fubarino Mini in more detail, as it is the same core just a different package with more pins.

Cheers Chris

caroper

Mon, 24 Jun 2013 19:00:08 +0000

Whilst I am on the subject of Pin Maps I would like to Define the two Chips to have the same Pin numbers on the same physical pins, that is on the MX150 RB6 would be ChipKIT pin 0 and on the MX250 it would be Vbus, therefore, there would be no ChipKIT pin 0 available on that device.

The idea being to have one board but be able to swap devices.

would I ba able to do that by defining both as 21 IO Pins and allocate the same pin numbers, but rely on the device itself to ignore IO on a non existent pin,

alternatively is there a similar NOT_IO_PIN type declaration?

Cheers Chris

EmbeddedMan

Mon, 24 Jun 2013 19:15:55 +0000

Chris, I think so. But I haven't tried that yet. Give it a shot and see if it works for you.

*Brian

caroper

Mon, 24 Jun 2013 19:30:08 +0000

Thanks Brian,

I think I am going to call it a night for now and go watch TV or listen to some music, I am going a bit cross eyed :)

I will resume in the morning when I am fresh.

Cheers Chris

caroper

Tue, 25 Jun 2013 19:23:51 +0000

just for the sake of closure, it worked.

I can now quite happily put a Sketch on an MX250, pop it out, drop in an MX150 and load the same Sketch, without having to redo the breadboard or change any Pin Numbers in the Sketch.

I am just refining and testing the Bootloaders and the Board definitions in different combinations as well as adding or removing stuff as I go, fine tuning.

When I have tasted at least the most common Arduino / Chipkit Sketches on them all and am happy with them, I will release to the community and I guess take on the daunting task of having to document them :)

Cheers Chris