Created Mon, 08 Jul 2013 20:58:23 +0000 by caroper
Mon, 08 Jul 2013 20:58:23 +0000
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:
/* 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:
//___________________________________________________________
//
// 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()
{
Serial.begin(19200);
Serial1.begin(19200);
mapPps(3, PPS_OUT_U2TX);
mapPps(2, PPS_IN_U2RX );
Serial1.print("Hello World!");
}
void loop()
{
if(Serial.available())
{
Serial1.print((char)Serial.read());
}
if(Serial1.available())
{
Serial.print((char)Serial1.read());
}
}
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.
Cheers Chris
[url]http://caroper.blogspot.com[/url]
p.s.
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.