CFA-633 to PIC serial issues

[hoveringuy]

This is a programmer (me) problem, not display.

I have a Microchip dsPIC30F4011 running on a development board with integrated MAX232 and such. I am trying to connect the CFA-633 in place of the existing SPI LCD. Using an oscilloscope I can see the Tx pin trying to send one character (or something) and then nothing.

the pertitenent parts of my code is as follows. The UART routines are straight from Microchip examples.

My desired display string is held in character type DisplayData.....
DisplayData [0] = 31; //LCD
DisplayData [1] =22; //length
DisplayData [2] = 0; //x
DisplayData [3] = 0; //y
DisplayData [4] ='H'; ...ello World.

The main routine calls WriteUART_to_RS232. This should activate the UART by loading the first character.....

void WriteUART_to_RS232(void)
{
if ((UARTCharPtr > &DisplayData[0]) &&
(UARTCharPtr < &DisplayData[38])) return;
else
{
UARTCharPtr = &DisplayData[0]; //Re-Initialize UART display
//buffer pointer to point to
//the first character
U1TXREG = *UARTCharPtr++; //Load the UART transmit
//register with first character
}
}

The interupt should load additional characters as the Tx buffer runs dry....

void __attribute__((__interrupt__)) _U1TXInterrupt(void)
{
int i = 0;
while ((*UARTCharPtr != '\0') && (i < 4))
{
U1TXREG = *UARTCharPtr++;
i++;
}
IFS0bits.U1TXIF = 0; //Clear the UART1 transmitter interrupt flag
}


What am I missing here?

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[cosmicvoid]

I looked at the datasheet, but only briefly, and I'm not familiar with this cpu.

I don't see any code that enables the U1TX interrupt, and interrupts in general. If you set a breakpoint on the ISR, does it ever get reached?

Since there is a FIFO, one wonders why, in void WriteUART_to_RS232(void), you don't attempt to fill it. If your output string is shorter than the FIFO depth, then the interrupt stuff doesn't need to be enabled.

Also, testing for '\0' as a terminator is not the way to do it. What do you think will happen when UARTCharPtr reaches &DisplayData[2] ??

 

[hoveringuy]

I don't see any code that enables the U1TX interrupt, and interrupts in general. If you set a breakpoint on the ISR, does it ever get reached???

I didn't include it for brevity.
U1MODEbits.UARTEN = 1; //Enable UART1 module
U1BRG = BRGVAL; //Load UART1 Baud Rate Generator

IFS0bits.U1RXIF = 0; //Clear UART1 Receiver Interrupt Flag
IFS0bits.U1TXIF = 0; //Clear UART1 Transmitter Interrupt Flag
IEC0bits.U1RXIE = 0; //Disable UART1 Receiver ISR
IEC0bits.U1TXIE = 1; //Enable UART1 Transmitter ISR
U1STAbits.UTXISEL = 1; //Setup UART1 transmitter to interrupt
//when a character is transferred to the
//Transmit Shift register and as result,
//the transmit buffer becomes empty.

U1STAbits.UTXEN = 1; //Enable UART1 transmitter
UARTCharPtr = &DisplayData[0]; //Initialize UARTCharPtr to point
//to the first character in the Display buffer

Since there is a FIFO, one wonders why, in void WriteUART_to_RS232(void), you don't attempt to fill it. If your output string is shorter than the FIFO depth, then the interrupt stuff doesn't need to be enabled.

True. But my standard string will be long enough that it will call the interupt. I am wondering if the interupt is even necessary, I could poll the output buffer with a While until the string is sent. I have interupts elsewhere if attention is needed there.

Also, testing for '\0' as a terminator is not the way to do it. What do you think will happen when UARTCharPtr reaches &DisplayData[2] ??

I've wondered about that, too. The alternative probably wouldn't use an interupt, either.

 

[cosmicvoid]

I figured that you left out the interrupt setup for brevity, but I had to ask anyway, you know . The question still remains unanswered: does the tx empty interrupt actually cause the ISR to execute? If not, there's your root problem.

Yeah, you could do the serial I/O by polling, but its much cooler to use the interrupt "set it and forget it" method.

As for determining when you have reached the end of data buffer on your serial transmission, did you have an alternative plan?

 

[hoveringuy]

I ditched the ISR (for now) and have it working better with a while (U1STAbits.UTXF==1).

The != '\0' is still problematic. For some reason it works if I have 10 items in my char array but not 11 or more.

I like the idea of the ISR as well and will do some more investigating on why it wasn't triggering.

Another question: most of my project is interupt driven. What happens if a hardware interupt ocurrs during a UART transmission? Will I lose that packet or is it robust enough to still work?

Steve in Bremerton, WA

 

[cosmicvoid]

The != '\0' is still problematic. For some reason it works if I have 10 items in my char array but not 11 or more.

You really need to use the string length as the way to control transmission. Every command has a known length (that's how the 633 knows what to expect), so you can use that number. That way, it remains totally independant of content; e.g. you could send a string of 30 nulls.

Steve in Bremerton, WA

Hmm, I'm in Kingston.

Another question: most of my project is interupt driven. What happens if a hardware interupt ocurrs during a UART transmission? Will I lose that packet or is it robust enough to still work?

It should work ok. The uart itself is not affected by interrupts.

 

[hoveringuy]

Progress!

I ditched the != '\0' as it was problematic.

I pass the string length and use a For routine the seems to be the standard. It works.

The O-scope shows a nice serial string with perfect 52uSecond bits.

I have the "Hello World" test string loaded with the hard-coded CRC bytes but the LCD hasn't responded to it yet. The pinout at the end of my WR-232-Y08 doens't match the LCD header for default RS-232. The development board has a female DB9 where a PC would normally have a male. I've used a male-male straight through to connect, I'll need to look more closely at the pinouts tonight, I was happy just to get the code working!

 

[hoveringuy]

Help! I've verified that I am ouputing complete and proper RS-232 signals to the proper pins on the 633. However, I haven't had the panel respond yet. I'm using the Crystal packet debugger to generate the CRC for "Hello World". It is simple code and I don't see what I'm missing.

void UpdateDisplayBuffer(void)
{
DisplayData[0] = 31; //LCD
DisplayData[1] = 18; //length
DisplayData[2] = 0; //x
DisplayData[3] = 0; //y
DisplayData[4] ='H';
DisplayData[5] ='e';
DisplayData[6] ='l';
DisplayData[7] ='l';
DisplayData[8] ='o';
DisplayData[9] =' ';
DisplayData[10]='W';
DisplayData[11]='o';
DisplayData[12]='r';
DisplayData[13]='l';
DisplayData[14]='d';
DisplayData[15]=' ';
DisplayData[16]=' ';
DisplayData[17]=' ';
DisplayData[18]=' ';
DisplayData[19]=' ';
DisplayData[20]= 174 ;
DisplayData[21]= 143 ;


WriteUART_to_RS232(DisplayData, 22);


#define XTFREQ 7372800 //On-board Crystal frequency
#define PLLMODE 8 //On-chip PLL setting
#define FCY XTFREQ*PLLMODE/4 //Instruction Cycle Frequency
#define BAUDRATE 19200 //Desired Baud Rate
#define BRGVAL ((FCY/BAUDRATE)/16)-1 //Formula for U1BRG register
//from dsPIC30F Family
//Reference Manual //Declaration to Link External Functions & Variables:
extern unsigned char DisplayData[];
//Functions and Variables with Global Scope:
void UART_Init (void);
void WriteUART_to_RS232(unsigned char* UARTCharPtr, int packet_length); void __attribute__((__interrupt__)) _U1TXInterrupt(void);

//unsigned char *UARTCharPtr;

//Functions
//UART_Init() sets up the UART for a 8-bit data, No Parity, 1 Stop bit at 19200 baud

void UART_Init (void)
{
U1MODE = 0x0000; //Clear UART2 registers
U1STA = 0x0000;
U1MODEbits.ALTIO = 1; //Enable U1ATX and U1ARX instead of
//U1TX and U1RX pins
U1MODEbits.UARTEN = 1; //Enable UART1 module
U1BRG = BRGVAL; //Load UART1 Baud Rate Generator
IFS0bits.U1RXIF = 0; //Clear UART1 Receiver Interrupt Flag
IFS0bits.U1TXIF = 0; //Clear UART1 Transmitter Interrupt Flag
IEC0bits.U1RXIE = 0; //Disable UART1 Receiver ISR
IEC0bits.U1TXIE = 0; //Disable UART1 Transmitter ISR
U1STAbits.UTXEN = 1; //Enable UART1 transmitter
}
//WriteUART_to_RS232() triggers interrupt-driven UART communication by writing
//the first character in the Display buffer to theUART Transmit register void

WriteUART_to_RS232(unsigned char* UARTCharPtr, int packet_length)
{
int *ptr;
int CRC,i;
ptr = UARTCharPtr;

for (i=0; i<packet_length; i++)
{
while (U1STAbits.UTXBF==1);
U1TXREG = UARTCharPtr;
}
}

 

[cosmicvoid]

The simplest thing I can find wrong is the CRC of the packet. According to my copy of 633WinTest, the CRC is 0xB5B4. Note the the lsb (0xB4) is sent first.

snip....
DisplayData[14]='d';
DisplayData[15]=' ';
DisplayData[16]=' ';
DisplayData[17]=' ';
DisplayData[18]=' ';
DisplayData[19]=' ';
DisplayData[20]= 0xB4;
DisplayData[21]= 0xB5;
snip....

Also, I highly recommend you put code that you want to post either as attachments or in a "code box", so that the formatting will be preserved. Notice in your previous post, the "for ()" loop at the bottom is partly missing, probably because the forum software interprets certain characters as tokens.

 

[hoveringuy]

Hello World....


Well I'll be ... IT WORKS!

Thanks for the correct CRC, CosmicVoid, that was the problem.

When I run 633 Wintest, I go to packet debugger and select command 31. For "Hello World " I'm getting this..

tC=31(31 = Send Data to LCD (row,col)),L=16,D="Hello World ",CRC=0x8FAE

I've tried no trailing spaces and trailing spaces.

Why is my CRC different than yours?? How did you get B5B4??

 

[hoveringuy]

Now that I know it's working end to end, my next task is to replace the hard-coded CRC with one generated dynamically.

I'm using the "get_crc" function copied with a few changes so it would compile. I'll mark the changes and my question areas...

void WriteUART_to_RS232(unsigned char* UARTCharPtr, int packet_length)
{

int *ptr;
int CRC,i;
ptr = UARTCharPtr;


CRC = get_crc(ptr, packet_length); 

for (i=0; i<packet_length; i++)
{
	while (U1STAbits.UTXBF==1);	
	U1TXREG = UARTCharPtr[i];
}

U1TXREG = (CRC & 0x00FF);   //How do I xmit LSB and then MSB?
while (U1STAbits.UTXBF==1);	
U1TXREG = (CRC >>8); 
}

void  get_crc( unsigned char *bufptr,int len)    //I replaced "word" with void, ubyte with unsigned char
{
//CRC lookup table to avoid bit-shifting loops.
static const char crcLookupTable[256] =
{0x00000,0x01189,0x02312,0x0329B,0x04624,0x057AD,0x06536,0x074BF,
0x08C48,0x09DC1,0x0AF5A,0x0BED3,0x0CA6C,0x0DBE5,0x0E97E,0x0F8F7,
0x01081,0x00108,0x03393,0x0221A,0x056A5,0x0472C,0x075B7,0x0643E,
0x09CC9,0x08D40,0x0BFDB,0x0AE52,0x0DAED,0x0CB64,0x0F9FF,0x0E876,
0x02102,0x0308B,0x00210,0x01399,0x06726,0x076AF,0x04434,0x055BD,
0x0AD4A,0x0BCC3,0x08E58,0x09FD1,0x0EB6E,0x0FAE7,0x0C87C,0x0D9F5,
0x03183,0x0200A,0x01291,0x00318,0x077A7,0x0662E,0x054B5,0x0453C,
0x0BDCB,0x0AC42,0x09ED9,0x08F50,0x0FBEF,0x0EA66,0x0D8FD,0x0C974,
0x04204,0x0538D,0x06116,0x0709F,0x00420,0x015A9,0x02732,0x036BB,
0x0CE4C,0x0DFC5,0x0ED5E,0x0FCD7,0x08868,0x099E1,0x0AB7A,0x0BAF3,
0x05285,0x0430C,0x07197,0x0601E,0x014A1,0x00528,0x037B3,0x0263A,
0x0DECD,0x0CF44,0x0FDDF,0x0EC56,0x098E9,0x08960,0x0BBFB,0x0AA72,
0x06306,0x0728F,0x04014,0x0519D,0x02522,0x034AB,0x00630,0x017B9,
0x0EF4E,0x0FEC7,0x0CC5C,0x0DDD5,0x0A96A,0x0B8E3,0x08A78,0x09BF1,
0x07387,0x0620E,0x05095,0x0411C,0x035A3,0x0242A,0x016B1,0x00738,
0x0FFCF,0x0EE46,0x0DCDD,0x0CD54,0x0B9EB,0x0A862,0x09AF9,0x08B70,
0x08408,0x09581,0x0A71A,0x0B693,0x0C22C,0x0D3A5,0x0E13E,0x0F0B7,
0x00840,0x019C9,0x02B52,0x03ADB,0x04E64,0x05FED,0x06D76,0x07CFF,
0x09489,0x08500,0x0B79B,0x0A612,0x0D2AD,0x0C324,0x0F1BF,0x0E036,
0x018C1,0x00948,0x03BD3,0x02A5A,0x05EE5,0x04F6C,0x07DF7,0x06C7E,
0x0A50A,0x0B483,0x08618,0x09791,0x0E32E,0x0F2A7,0x0C03C,0x0D1B5,
0x02942,0x038CB,0x00A50,0x01BD9,0x06F66,0x07EEF,0x04C74,0x05DFD,
0x0B58B,0x0A402,0x09699,0x08710,0x0F3AF,0x0E226,0x0D0BD,0x0C134,
0x039C3,0x0284A,0x01AD1,0x00B58,0x07FE7,0x06E6E,0x05CF5,0x04D7C,
0x0C60C,0x0D785,0x0E51E,0x0F497,0x08028,0x091A1,0x0A33A,0x0B2B3,
0x04A44,0x05BCD,0x06956,0x078DF,0x00C60,0x01DE9,0x02F72,0x03EFB,
0x0D68D,0x0C704,0x0F59F,0x0E416,0x090A9,0x08120,0x0B3BB,0x0A232,
0x05AC5,0x04B4C,0x079D7,0x0685E,0x01CE1,0x00D68,0x03FF3,0x02E7A,
0x0E70E,0x0F687,0x0C41C,0x0D595,0x0A12A,0x0B0A3,0x08238,0x093B1,
0x06B46,0x07ACF,0x04854,0x059DD,0x02D62,0x03CEB,0x00E70,0x01FF9,
0x0F78F,0x0E606,0x0D49D,0x0C514,0x0B1AB,0x0A022,0x092B9,0x08330,
0x07BC7,0x06A4E,0x058D5,0x0495C,0x03DE3,0x02C6A,0x01EF1,0x00F78};
//register int newCrc;   //commented out replaced with int newCrc..
int newCrc=0xFFFF;
while(len--)
newCrc = (newCrc >> 8) ^ crcLookupTable[(newCrc ^ *bufptr++) & 0xff];
//Make this crc match the one’s complement that is sent in the packet.
return(~newCrc);
}

 

[cosmicvoid]

tC=31(31 = Send Data to LCD (row,col)),L=16,D="Hello World ",CRC=0x8FAE
I've tried no trailing spaces and trailing spaces.
Why is my CRC different than yours?? How did you get B5B4??

Notice that in your packet, quoted here, the length is 16. I took the sample from your earlier post in which the length is 18; look at my screen capture. You didn't use enough trailing spaces.

[COLOR="Red"][B]void[/B][/COLOR] get_crc( unsigned char *bufptr,int len)  [COLOR="Red"][B]//I replaced "word" with void, ubyte with unsigned char[/B][/COLOR]
{
//CRC lookup table to avoid bit-shifting loops.
static const char crcLookupTable[256] =
snip....
//Make this crc match the one’s complement that is sent in the packet.
[COLOR="Red"][B]return(~newCrc);[/B][/COLOR]
}

If you replace WORD with VOID, then the function cannot return anything, so your compiler will laugh at your "return(~newCrc);" statement. So set it back to WORD.
"Ubyte" and "unsigned char" are equivalent.

snip....
for (i=0; i<packet_length; i++)
{
    while (U1STAbits.UTXBF==1);    
    U1TXREG = UARTCharPtr[i];
}

U1TXREG = (CRC & 0xFF);   //How do I xmit LSB and then MSB?
while (U1STAbits.UTXBF==1);    
U1TXREG = (CRC >> 8); 
}

You are doing it correctly. You ought to add another busy check before the LSB write.

 

[hoveringuy]

Notice that in your packet, quoted here, the length is 16. I took the sample from your earlier post in which the length is 18; look at my screen capture. You didn't use enough trailing spaces.

I gathered that there is a difference in the length that the debugger reports and the length of the data payload, which includes the x,y coordinates. Doesn't the L=16 imply a data string length of 18 when you add the x & y? When I add two more trailing spaces I still get this:

tC=31(31 = Send Data to LCD (row,col)),L=18,D="Hello World ",CRC=0x6AE5

If you replace WORD with VOID, then the function cannot return anything, so your compiler will laugh at your "return(~newCrc);" statement. So set it back to WORD.

I don't think my C30 compiler understands the type WORD. Since CRC is getting the returned value, and CRC is an int, can't I say

int get_crc( unsigned char *bufptr,int len)?

I tried that change and it didn't work, unfortunately.

I also don't think I can do this

static const char crcLookupTable[256] =
{0x00000,0x01189,0x02312,0x0329B,0x04624,0x057AD,0x06536,0x074BF,

because I'm trying to stuff 16 bits into a character type. Again, what is the Microchip C++ equivalent of WORD?

You ought to add another busy check before the LSB write.

That's a good point!

 

[cosmicvoid]

I gathered that there is a difference in the length that the debugger reports and the length of the data payload, which includes the x,y coordinates. Doesn't the L=16 imply a data string length of 18 when you add the x & y? When I add two more trailing spaces I still get this:
tC=31(31 = Send Data to LCD (row,col)),L=18,D="Hello World ",CRC=0x6AE5

The debugger reports the length of the data payload, regardless of what the bytes mean. For command 31, L = 18 means the x & y bytes plus 16 characters. In your example here, you have
L=18,D="Hello..."
instead of
L=18,D="\000\000Hello..."

I don't think my C30 compiler understands the type WORD.

#typedef unsigned int WORD
#typedef unsigned char BYTE

Your compiler support might have an include file that has these common types defined.

I also don't think I can do this:
static const char crcLookupTable[256] =
{0x00000,0x01189,0x02312,0x0329B,0x04624,0x057AD,0x06536,0x074BF,

because I'm trying to stuff 16 bits into a character type. Again, what is the Microchip C++ equivalent of WORD?

unsigned int, as in:
static const WORD crcLookupTable[256]

 

[hoveringuy]

L=18,D="\000\000Hello..."

I did get that working and verified the CRC this morning. I understand why I am doing it but the inplementation in WinTest is clear as mud! WinTest should have a separate set of boxes where "x" and "y" are input serparately. It would clear-up a lot of confusion!

I won't have time for the other stuff until tonight, but practically speaking, what is the difference between using WORD and an int? If I am going to TYPEDEF WORD as an unsigned int, why can't I just use int??

 

[cosmicvoid]

.... WinTest should have a separate set of boxes where "x" and "y" are input serparately. It would clear-up a lot of confusion!

Maybe, but only one command needs the X,Y parameters. The data meaning for each command is mostly different, so for most commands the data entry field might have all binary values and no text. Its up to the user to use the packet protocol info in the data sheet to format the packet correctly. The debugger is not a full-featured UI.

I won't have time for the other stuff until tonight, but practically speaking, what is the difference between using WORD and an int? If I am going to TYPEDEF WORD as an unsigned int, why can't I just use int??

You do realize that "int" and "unsigned int" are not equivalent? Variables are signed unless declared unsigned. In some cases, using either would work ok, but you should be careful to declare the variable type appropriately. The result of arithemetic operations depends on it.

 

[hoveringuy]

I finally got my display to work, with dynamic CRC generation. Many Thanks to CosmicVoid for your patient help! I still don't understand why using WORD is different than unsigned int, but I'll take what I can get...

I will post what I have in my UART module for those following behind me. This is for a Microchip dspic30F4011 but should be easily adaptable to most PICs:

//Pre-Processor Directives:
#include <p30fxxxx.h>
#define XTFREQ          7372800         //On-board Crystal frequency
#define PLLMODE         8               //On-chip PLL setting
#define FCY             XTFREQ*PLLMODE/4        //Instruction Cycle Frequency
#define BAUDRATE        19200                    //Desired Baud Rate
#define BRGVAL          ((FCY/BAUDRATE)/16)-1   //Formula for U1BRG register
                                                //from dsPIC30F Family
                                                //Reference Manual
typedef unsigned int WORD;
typedef unsigned char BYTE;

//Declaration to Link External Functions & Variables:
extern  unsigned char DisplayData[];

//Functions and Variables with Global Scope:
void UART_Init (void);
void WriteUART_to_RS232(unsigned char* UARTCharPtr, int packet_length);
void __attribute__((__interrupt__)) _U1TXInterrupt(void);
WORD get_crc(BYTE *bufptr,WORD len);


//UART_Init() sets up the UART for a 8-bit data, No Parity, 1 Stop bit
//at 19200 baud with transmitter interrupts enabled
void UART_Init (void)
{
        U1MODE = 0x0000;        //Clear UART2 registers
        U1STA = 0x0000;
        U1MODEbits.ALTIO = 1;   //Enable U1ATX and U1ARX instead of
                                //U1TX and U1RX pins

        U1MODEbits.UARTEN = 1;  //Enable UART1 module
        U1BRG = BRGVAL;         //Load UART1 Baud Rate Generator

        IFS0bits.U1RXIF = 0;    //Clear UART1 Receiver Interrupt Flag
        IFS0bits.U1TXIF = 0;    //Clear UART1 Transmitter Interrupt Flag
        IEC0bits.U1RXIE = 0;    //Disable UART1 Receiver ISR
        IEC0bits.U1TXIE = 0;    //Enable UART1 Transmitter ISR
        U1STAbits.UTXEN = 1;    //Enable UART1 transmitter
}

//WriteUART_to_RS232() triggers interrupt-driven UART communication by writing
//the first character in the Display buffer to theUART Transmit register


void WriteUART_to_RS232(unsigned char* UARTCharPtr, int packet_length)
{

int *ptr;
int CRC,i;
ptr = UARTCharPtr;


CRC = get_crc(ptr, packet_length); 

for (i=0; i<packet_length; i++)
{
	while (U1STAbits.UTXBF==1);	
	U1TXREG = UARTCharPtr[i];
}

while (U1STAbits.UTXBF==1);               //wait for xmit register to be empty
U1TXREG = (CRC & 0x00FF);                 //send the LSB to register by ANDing 
while (U1STAbits.UTXBF==1);	   //wait for xmit register to be empty
U1TXREG = (CRC >>8); 		   //write the MSB by bit shifting to the right by 8

}


//CRC lookup table taken verbatim from CrystalFontz

WORD get_crc(BYTE *bufptr,WORD len)
{
static const WORD crcLookupTable[256] =
{0x00000,0x01189,0x02312,0x0329B,0x04624,0x057AD,0x06536,0x074BF,
0x08C48,0x09DC1,0x0AF5A,0x0BED3,0x0CA6C,0x0DBE5,0x0E97E,0x0F8F7,
0x01081,0x00108,0x03393,0x0221A,0x056A5,0x0472C,0x075B7,0x0643E,
0x09CC9,0x08D40,0x0BFDB,0x0AE52,0x0DAED,0x0CB64,0x0F9FF,0x0E876,
0x02102,0x0308B,0x00210,0x01399,0x06726,0x076AF,0x04434,0x055BD,
0x0AD4A,0x0BCC3,0x08E58,0x09FD1,0x0EB6E,0x0FAE7,0x0C87C,0x0D9F5,
0x03183,0x0200A,0x01291,0x00318,0x077A7,0x0662E,0x054B5,0x0453C,
0x0BDCB,0x0AC42,0x09ED9,0x08F50,0x0FBEF,0x0EA66,0x0D8FD,0x0C974,
0x04204,0x0538D,0x06116,0x0709F,0x00420,0x015A9,0x02732,0x036BB,
0x0CE4C,0x0DFC5,0x0ED5E,0x0FCD7,0x08868,0x099E1,0x0AB7A,0x0BAF3,
0x05285,0x0430C,0x07197,0x0601E,0x014A1,0x00528,0x037B3,0x0263A,
0x0DECD,0x0CF44,0x0FDDF,0x0EC56,0x098E9,0x08960,0x0BBFB,0x0AA72,
0x06306,0x0728F,0x04014,0x0519D,0x02522,0x034AB,0x00630,0x017B9,
0x0EF4E,0x0FEC7,0x0CC5C,0x0DDD5,0x0A96A,0x0B8E3,0x08A78,0x09BF1,
0x07387,0x0620E,0x05095,0x0411C,0x035A3,0x0242A,0x016B1,0x00738,
0x0FFCF,0x0EE46,0x0DCDD,0x0CD54,0x0B9EB,0x0A862,0x09AF9,0x08B70,
0x08408,0x09581,0x0A71A,0x0B693,0x0C22C,0x0D3A5,0x0E13E,0x0F0B7,
0x00840,0x019C9,0x02B52,0x03ADB,0x04E64,0x05FED,0x06D76,0x07CFF,
0x09489,0x08500,0x0B79B,0x0A612,0x0D2AD,0x0C324,0x0F1BF,0x0E036,
0x018C1,0x00948,0x03BD3,0x02A5A,0x05EE5,0x04F6C,0x07DF7,0x06C7E,
0x0A50A,0x0B483,0x08618,0x09791,0x0E32E,0x0F2A7,0x0C03C,0x0D1B5,
0x02942,0x038CB,0x00A50,0x01BD9,0x06F66,0x07EEF,0x04C74,0x05DFD,
0x0B58B,0x0A402,0x09699,0x08710,0x0F3AF,0x0E226,0x0D0BD,0x0C134,
0x039C3,0x0284A,0x01AD1,0x00B58,0x07FE7,0x06E6E,0x05CF5,0x04D7C,
0x0C60C,0x0D785,0x0E51E,0x0F497,0x08028,0x091A1,0x0A33A,0x0B2B3,
0x04A44,0x05BCD,0x06956,0x078DF,0x00C60,0x01DE9,0x02F72,0x03EFB,
0x0D68D,0x0C704,0x0F59F,0x0E416,0x090A9,0x08120,0x0B3BB,0x0A232,
0x05AC5,0x04B4C,0x079D7,0x0685E,0x01CE1,0x00D68,0x03FF3,0x02E7A,
0x0E70E,0x0F687,0x0C41C,0x0D595,0x0A12A,0x0B0A3,0x08238,0x093B1,
0x06B46,0x07ACF,0x04854,0x059DD,0x02D62,0x03CEB,0x00E70,0x01FF9,
0x0F78F,0x0E606,0x0D49D,0x0C514,0x0B1AB,0x0A022,0x092B9,0x08330,
0x07BC7,0x06A4E,0x058D5,0x0495C,0x03DE3,0x02C6A,0x01EF1,0x00F78};
//register int newCrc;
WORD newCrc=0xFFFF;
while(len--)
newCrc = (newCrc >> 8) ^ crcLookupTable[(newCrc ^ *bufptr++) & 0xff];
//Make this crc match the one’s complement that is sent in the packet.
return(~newCrc);
}

Here is how I call from the main routine:

unsigned char *LCDCharPtr;
unsigned char DisplayData[40];

void UpdateDisplayBuffer(void)
{
DisplayData[0] = 31;   //LCD
DisplayData[1] = 18;   //length
DisplayData[2] = 0;    //x
DisplayData[3] = 0;    //y
DisplayData[4] ='H';
DisplayData[5] ='e';
DisplayData[6] ='l';
DisplayData[7] ='l';
DisplayData[8] ='o';
DisplayData[9] =' ';
DisplayData[10]='W';
DisplayData[11]='o';
DisplayData[12]='r';
DisplayData[13]='l';
DisplayData[14]='d';
DisplayData[15]=' ';
DisplayData[16]=' ';
DisplayData[17]=' ';
DisplayData[18]=' ';
DisplayData[19]=' ';

WriteUART_to_RS232(DisplayData, 20);

I'm sure I'll have more questions when it comes time to read button inputs but I hope this helps someone for now!

 

[cosmicvoid]

I still don't understand why using WORD is different than unsigned int, but I'll take what I can get...

Its not different; you are defining them to be equivalent with the typdef statement. Many people prefer the 4-letter typename to the 12-letter typename.

 

[hoveringuy]

I now have it connected exclusively through 8 ft of regular phone wire, 4 conductor. No issues, works great.

RJ-11 jack is very convenient for connecting/disconnecting it!