This is going to be a detailed technical post on MPLB X, XC8 PIC C compiler and how not to code a project. Or to put it simply, how not to be stupid.
The above picture is a Curiosity HPC Development Board that I talked about in this post. This was to help me get most of the code structure working for the Brick Buddy III as shown here.
The processor on the PCB is a PIC18F26Q71. Fairly new, but with a very nice of features and lots of program FLASH and RAM. But it was going to be weeks before I received one from assembly. Thus the HPC was put into use. Instead of putting a PIC18F26Q71 in the HPC (it does have a 28 pin socket underneath the 40 pin DIP), I chose to use the 40 pin version, a PIC18F46Q71. The only difference between the two, besides the physical 28 pins vs 40 pins, is the PIC18F46Q71 has an extra PORT (PORT D).
The Brick Buddy III code is a derivative of Brick Buddy II and Light Buddy II. I have not started a project completely from scratch in a long time. Using common libraries as I explained in this post means that only the main control loop and the hardware initialization is unique, unless there is a new peripheral of some kind. Once I updated the initialization, I started compiling the code with the PIC18F26Q71 as the processor. This PIC has the new I2C controller and thus there was a few days of just getting the code to compile. During the compilation, there were multiple error messages having do with available PIC ports. Brick Buddy II is a 44 pin device and thus has a PORT D. All of this had to be changed to accommodate the PIC PORTS available on the PIC18F26Q71.
Once that was done I started trying to see if I could get some of the basic structure working. This include the serial interface to the PC, the I2C EEPROM that stores configuration and scripts (which would also validate the I2C software driver for the LP5569 IC LED driver). Finally working on the Bluetooth code for the RN4871. This BT module is similar to the RN4020, but I am sure there will be some minor road bumps.
Once I had my standard LED heartbeat running, I moved on to the serial interface. The PCB contains a FTDI USB to UART interface IC. So I used one of my lab ones to connect the PC to the HPC Development Board with three jumper wires (Rx, Tx & GND). And nothing worked.
Most PICs have a Peripheral Pin Select (PPS) module. This allows you to move digital peripheral features to different pins. It is basically a large switch matrix. Some PICs can move the peripherals to any pin while others will restrict a peripheral to a subset of the PORTS. Thus there is code at initialization that has to be executed to move the peripheral output to the desired pin. This is shown here
#if defined(USE_PCB)
INT2PPS = 0x01; // assign INT1 to RA0
INT0PPS = 0x08; // assign INT0 to RB0
U1RXPPS = 0x0B; // assign Rx1 to RB3 --RN4871
U2RXPPS = 0x0C; // assign Rx2 to RB4 --Console
I2C1SCLPPS = 0x13; // assign SCL1 to RC3
I2C1SDAPPS = 0x14; // assign SDA1 to RC4
RC3PPS = 0x20; // assign SCL1 to RC3
RC4PPS = 0x21; // assign SDA1 to RC4
RB2PPS = 0x15; // assign Tx1 to RB2 --RN4871
RB5PPS = 0x18; // assign Tx2 to RB5 --Console
RC2PPS = 0x0D; // assign CCP1 to RC2
RC5PPS = 0x0E; // assign CCP2 to RC5
RC6PPS = 0x0F; // assign PWM1 to RC6
RC7PPS = 0x11; // assign PWM2 to RC7
#elif defined(USE_DEV_BRD)
INT2PPS = 0x15; // assign INT1 to RC5
INT0PPS = 0x0C; // assign INT0 to RB4
U1RXPPS = 0x10; // assign Rx1 to RC0 --RN4871
U2RXPPS = 0x0D; // assign Rx2 to RB5 --Console
//U2RXPPS = 0x19; // assign Rx2 to RD1 --Console
I2C1SCLPPS = 0x13; // assign SCL1 to RC3
I2C1SDAPPS = 0x14; // assign SDA1 to RC4
RC3PPS = 0x20; // assign SCL1 to RC3
RC4PPS = 0x21; // assign SDA1 to RC4
RC1PPS = 0x15; // assign Tx1 to RC1 --RN4871
RD0PPS = 0x18; // assign Tx2 to RD0 --Console
RC2PPS = 0x0D; // assign CCP1 to RC2
RC5PPS = 0x0E; // assign CCP2 to RC5
RC6PPS = 0x0F; // assign PWM1 to RC6
RC7PPS = 0x11; // assign PWM2 to RC7
RD1PPS = 0x00;
#endif
What this also shows is that I have a conditional compile. One version for the PCB and one for the HPC Development Board. What I found was that UART2 Rx pin would not work on any of the PORT D pins, even though the data sheet clearly indicated that it good be moved to either PORT B or PORT D. The UART2 Tx pin worked on any of the PORT D pins I placed it on. I verified that there was a signal present using my Digilent Analog Discover 2 (which I highly recommend). Thus I moved the UART2 Rx pin to PORT B and all was good. I needed to make progress, so I moved on. Though I did post in the Microchip Support Forum what had happened.
Well someone commented on the post. When I read the comment, I immediately knew that person had the correct answer and I had fallen again for what I discussed a month ago in this post. Embarrassment does not even begin to describe how I felt.
Here is the initialization code with the issue
TRISA = 0xFF;
TRISB = 0xFF;
TRISC = 0xFF;
LATA = 0;
LATC = 0;
ANSELA = 0x00; //all digital
ANSELB = 0x00; //all digital
ANSELC = 0x00; //all digital
ADCON0 = 0x00; //A2D off
ADCON1 = 0x00; //+ref is Vdd and -ref is Vss
#if defined (USE_PCB)
mLED_TRIS = OUTPUT_PIN; // make it an output
#elif defined(USE_DEV_BRD)
mLED_B_TRIS = OUTPUT_PIN; // make it an output
mLED_Y_TRIS = OUTPUT_PIN; // make it an output
#endif
I had the foresight to place a conditional compile for the heartbeat LED (mLED_B & mLED_Y) to control the TRIS control for the pin. But if you look directly above that, you will notice there is no mention of either TRISD or ANSELD.
Now TRISx controls whether the PORT pin is an input or an output. The default is INPUT, but I always like to set them all to inputs and then let the code determine which pins are inputs and which are outputs. ANSELx controls whether the PORT is an analog input pin or a digital I/O pin. The default is analog input pin, but again I choose to make all port pins digital I/O and then let the code set those pins that will have an analog input.. But this code fragment does not set PORT D to digital I/O and thus all the PORT D pins are analog inputs.
Now the quirk in these PICs is that a digital output (TRISx = 0) will override the analog input selection. But a digital input will not override the analog input selection. If you think about this, that only makes sense. When you want an analog input ( e.g. ADC input) you will set the TRIS register to input and the ANSEL register to input. The only setup for the processor to know that you want a digital input is the ANSEL register has to be set correctly. So here is what the code fragment looks like now.
// Make all digital inputs for now and let init routines set the tris bits that need to be outputs.
TRISA = 0xFF;
TRISB = 0xFF;
TRISC = 0xFF;
LATA = 0;
LATC = 0;
ANSELA = 0x00; //all digital
ANSELB = 0x00; //all digital
ANSELC = 0x00; //all digital
ADCON0 = 0x00; //A2D off
ADCON1 = 0x00; //+ref is Vdd and -ref is Vss
#if defined (USE_PCB)
mLED_TRIS = OUTPUT_PIN; // make it an output
#elif defined(USE_DEV_BRD)
TRISD = 0xFF;
LATD = 0x00;
ANSELD = 0x00; // all digital
mLED_B_TRIS = OUTPUT_PIN; // make it an output
mLED_Y_TRIS = OUTPUT_PIN; // make it an output
#endif
Live and learn, maybe😕
No comments:
Post a Comment