Electronic – Is it possible to enable both UART and PLL at the same time on PIC18F

**EDIT 6/19/2012***********************************************************

Ok, so after you added your code I have made a few changes for you to try (and to understand!)

First of all, we have declared our character array volatile so that the compiler knows it may change unexpectedly from an interrupt. Likewise, we have created a variable to keep track of our index position in the array:

/**************************************************
 *  Global Variables
 */
int trigger=0, length=0;
int i=0, n=0;
uint8_t data;
volatile char arr[8];
volatile char arr_idx = 0;

Next, i have edited your UART initialization code based on the ATMega16L Datasheet and your comments:

//USART SETUP
UCSRA = 0x00; //no Frame Error, no parity error, no Data OverRun
UCSRB = 0xD8; //receiver enable, transmitter enable (0x18)
UCSRC = 0x86; //Asynchronous USART mode, no parity, 1 stop bit, 8-bit character size, Data transmitted on rising edge and received on falling edge of the clock
UBRRL = 51; //Baud rate of 9600bps (8MHz clock?)
UBRRH = 0;

Look closely at the datasheet (page ~166). I believe I have correctly configures the UART now based on your comments. I will not go over each bit, but you should. Please ask questions if you think I made a mistake or you don't get something.

Finally, I have edited your ISR routine:

ISR(USART_RXC_vect){
    arr[arr_idx] = UDR;
    arr_idx++;
    arr_idx %= 7; //make sure index stays within array

    trigger = 1;
}

Note that, the ISR is executed every time a single byte (or character) is received. This means we want to process the single character (add it to our array), increment our index location, and get out of it quickly so that we are ready for the next character to come in.

You now need to look at the arr[] through whatever method you have been using and see if it is now receiving your characters correctly.

**END OF EDIT****************************************

One option is to just use one of the available libraries included in AVR Studio:

#include <stdlib.h>

and then somewhere in your code...

char num2[5]; //create a buffer for the ascii string
itoa(num1,num2,10); //convert the integer (num1) to an ascii string (num2) in base 10

If you are then displaying this on a character LCD, you can send the num2 array to the lcd print function that you are using.

If you are concerned about code space you can fairly easily write your own simple itoa (integer to ascii) function. You will need to grab each "tens" position from your integer using the "/" and "%" operators and convert it to ascii:

_{(source: asciitable.com)}

From the table above, you can see that once you grab each digits value (0-9), just add 48 to it to convert it into the ascii character representation.

EDIT

Ok, so after you adding your information and assuming:

• You have correctly initialized the UART baud rate etc on your ATMEGA
• The android code is successfully sending the ascii bytes across the WiFly and out of its UART

Then the microcontroller should already be receive these characters as Ascii, and the ITOA function is not what is needed here and in fact would mess up your string data coming in.

It could still be a lot of different things though...How are you viewing the uart data that is being received by your microcontroller?

According to the datasheet, the CAN module overrides the TRIS for CANTX but not for CANRX, which you must set yourself to be an input. Another flag that will prevent CAN recieve is CIOCONbits.CANCAP which should be 1 for enable CAN capture.