chipKIT DP32 - PPS

Post Reply
Posts: 120
Joined: Sun Jul 24, 2011 12:12 am

chipKIT DP32 - PPS

Post by caroper » Mon Jul 08, 2013 9:58 pm

I have spent a few days playing with PPS on the chipKIT DP32 Board and in the process I discovered a few anomalies. As I seem to be one of a only handful of people that are actively using PPS so far, I thought I would document them here to save others having to go through the same learning curve.

The UARTS are pre mapped in the Bootloader/Board definition and I wanted to be able to remap them at will.

I found that whilst the statements:

mapPps(3, PPS_OUT_U2TX);
mapPps(2, PPS_IN_U2RX );

worked, in that they returned TRUE, U2TX now correctly sent out on the new pin but continued to receive on PIN 10 (RA1).

I decided to try clearing the PPS assignments first and found that whilst:

mapPps(7, PPS_OUT_GPIO);

is valid and clears the output assignment, I could find no equivalent for clearing the Input. My workaround was to use:

U2RXR = 0xF;

Effectively resetting the PPS Register for UART2 Rx to the default state.

However, it did not solve the problem.

Next up was to use

pinMode(3, OUTPUT);

But still had no effect.

In desperation I modified the Board_Defs.h file and commented out the section that assigns the PIN mapping:

Code: Select all

/* Serial port 1 uses UART2
#define       _SER1_BASE           _UART2_BASE_ADDRESS
#define       _SER1_IRQ            _UART2_ERR_IRQ
#define       _SER1_VECTOR         _UART_2_VECTOR
#define       _SER1_IPL_ISR        _UART2_IPL_ISR
#define       _SER1_IPL            _UART2_IPL_IPC
#define       _SER1_SPL            _UART2_SPL_IPC
//#define       _SER1_TX_OUT         PPS_OUT_U2TX     // RPB14R = U2TX = 2
//#define       _SER1_TX_PIN         7                // RB14 CVREF/AN10/C3INB/RPB14/VBUSON/SCK1/CTED5/RB14
//#define       _SER1_RX_IN          PPS_IN_U2RX      // U2RXR = RPA1 = 0
//#define       _SER1_RX_PIN         10               // RA1  PGEC3/VREF-/CVREF-/AN1/RPA1/CTED2/PMD6/RA1 
to my surprise it still compiled ok but continued to use PIN 10 for Rx. It would appear that the code in Board_Defs.h is redundant.

As I could find no other code in either the Bootloader or the Boards files that actually assigned the PIN's I was about to give up and ask, when I decided to try one last test.

I placed the PPS Mapping after the Serial1.begin() statement and it worked!
Here then is my final test code:

Code: Select all

//  chipKIT DP32 Example 3
//    Remapping the UART with PPS
//  C.A.Roper - 2013
//  By default UART2 is connected to chipKIT PINs 7 and 10
//  (RB14 and RA1) this Sketch remaps it to PINS 2 and 3
//  (RB8 and RB9). These PINS were chosen as they are 5V 
//  tolerant and should work with any USB to Serial converter 
//  Cable or Board with no risk of damage to the DP32.
//  Note that the UART must be initialised prior to remapping 
//  the pins. The PIC UART Peripherals override any TRIS 
//  Register setting so there is no need to set pinMode.
//  The code will send a "Hello World!" out of UART2 to confirm
//  the connection and then enter pass-threw mode. Anything 
//  typed in the Serial Monitor should appear on the device
//  connected to UART2 and visa versa. 
//  If you do not have a suitable Serial to USB cable, it may 
//  be tested by shorting chipKIT PINs 2 and 3. This will make
//  UART2 loop back and anything typed in the Console will ECHO.
void setup()
  mapPps(3, PPS_OUT_U2TX);
  mapPps(2, PPS_IN_U2RX );
  Serial1.print("Hello World!");

void loop()
It sounds counter intuitive to assign the pins after initialising the port, but it works, and I rather like this behaviour.

Imagine a scenario with several remote Serial devices, such as RFID tag readers attached. Rather than having a UART per RFID Reader it may be possible to use PPS to remap and scan several Rx pins in sequence with a single UART.



Be aware the resetting the device will drop the USB connection and then reconnect, therefore, if you wish to reset the device to send "Hello World!" remember to close Serial Monitor First. If not it will lose its connection without actually closing.
It led me to bark up the wrong tree several times whilst debugging this, you are forewarned.

I also tried removing JP4 and 5 in case they effected things but my final solution works fine with them reinstalled.

Post Reply