635 & ttl serial w/ PIC

cjs

New member
hi;

i have a pic18 micro interfacing to a 635 lcd over ttl serial. i've attached my test code below, i'm simply trying to send data to the lcd for now, thus far i've been unsuccesful and nothing displays. i'm also printing out to a second lcd over digital outputs for string verification. the string appears on the second lcd screen as 3110TKHI! and the crc result is 60200 displayed as a 16bit integer. parsing the string...31-->cmd write to lcd....10-->data length....TKHI!-->data string.

does anyone see what's missing, i've compared to the win test code but obviously something is incorrect.

serial setting: #use rs232(uart1, baud=115200,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8)
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 

Attachments

Heffo

New member
The 635 is an intelligent LCD with more functions than just writing to a screen, so you can't just write text into it with a CRC on the end.

If you look in the 635's datasheet you will find a section on the packet structure and the list of commands available, it is quite extensive and there are plenty of posts on the forum in regards to the structure.

As a quick test, try sending this to your 635 as your packet.

Code:
packet_buffer[0] = 33; // Command 33 'Send Data To LCD'
packet_buffer[1] = 12; // Data Length = 12 Bytes
packet_buffer[2] = 0; // Column 0
packet_buffer[3] = 0; // Row 0
packet_buffer[4] = '3';
packet_buffer[5] = '1';
packet_buffer[6] = '1';
packet_buffer[7] = '0';
packet_buffer[8] = 'T';
packet_buffer[9] = 'K';
packet_buffer[10] = 'H';
packet_buffer[11] = 'I';
packet_buffer[12] = '!';
 

cjs

New member
no dice....i think the command you mean is "31", but tried both with no result....tried changing the packet_buffer array decleration from int to char as well

if that code snippet you provided should work, then the next culprit may be the crc code. i'm using the ccs pic compiler and have tried thier own example crc code as well as the code provided in the datasheet, with modified variables to allow it to compile, but am still unable to get communication.
 

Heffo

New member
The 635 will send an acknowledgment packet in return if the packet is in the correct format. If you got the CRC wrong it should send an error packet. If you check for data coming back from the display then you will at least know that the connection working.
 

cjs

New member
This post has an example packet in it:
https://forum.crystalfontz.com/showthread.php?t=5003
the byte order of the CRC packet is important.
the crc result given in the example packet in this link does not seem match what the packet debugger puts out in wintest....

i hardcoded this into the pic to see if the lcd would respond, the crc result comes from the wintest packet debug screen. i tried swapping the crc bytes but no results. tried various formats as well as well as swapping the crc bytes for good measure...text only "HELLO" to TYPE "00" + CMD "31" + LENGTH "7" + CURSOR POSITION "0" + "0" + TEXT "HELLO" and everything in between.
This is just some sample code i wrote up to test these various formats.
PHP:
crc1 = 0x96;
crc2 = 0x4D;

DELAY_MS(500);

while (1)
{
OUTPUT_HIGH(DIR_PIN);
DELAY_MS(100);
OUTPUT_LOW(DIR_PIN);
DELAY_MS(100);
putc(packet.command);		
putc(packet.data_length);
putc(packet.data[0]);
putc(packet.data[1]);
putc(packet.data[2]);
putc(packet.data[3]);
putc(packet.data[4]);
putc(packet.data[5]);
putc(packet.data[6]);
putc(crc1);
putc(crc2);
}
so i'm at an impasse here as to what to try next....
 
Last edited:
i have a pic18 micro interfacing to a 635 lcd over ttl serial.
I assume that means you are not using a rs232 driver chip. Are you connected directly from the PIC pins to the 635? If so, that may be your problem, as the rs232 data signal is inverted compared to the I/O pins on the mcu, so you may need to add inverters for TX and RX.
 

cjs

New member
no i'm not using a driver chip...the wires are connected as per the 635 H1 connector diagram w/ the host tx going to the lcd rx etc.

i'm leaning towards the crc code being the problem, i'm using the c code listed in the manual appendix, ported over to compile w/ my app but the results are way out to lunch when compared with the packet debugger output in the wintest software, its not a matter of bytes being swapped or cut off, for instance the crc produced by the wintest code for string "31 00 ELLO" is 0xAC75...the code produces a 0x253D

crc code:
PHP:
#include <stdio.h>
#include "crc.h"

unsigned short get_crc( unsigned char *bufptr, unsigned short len )
{
	int32 newCRC;
	int16 kerk;
	unsigned char data;
	int bit_count;

	newCRC = 0x00F32100;

	while (len--)
	{
		data = *bufptr++;

		for ( bit_count = 0; bit_count <= 7; bit_count++ )
		{
			newCRC >>= 1;

			if ( data & 0x01 )
				newCRC |= 0x00800000;

			if ( newCRC & 0x00000080 )
				newCRC ^= 0x00840800;
			data >>= 1;
		}
	}

	for ( bit_count = 0; bit_count <= 15; bit_count++ )
	{
		newCRC >>= 1;

		if ( newCRC & 0x00000080 )
			newCRC ^= 0x00840800;
	}

	kerk  = ~newCRC >> 8;

		printf(lcd_putc,"%LX", kerk);        //output result to a second lcd screen run through digital I/O
		delay_ms(100);

	return ( (~newCRC) >> 8 );
}
 

CF Tech

Administrator
Please try this simpler CRC algorithm:
Code:
#define POLY 0x8408
unsigned short get_crc(unsigned char count,unsigned char *ptr)
  {
  unsigned short
    crc;   //Calculated CRC
  unsigned char
    i;     //Loop count, bits in byte
  unsigned char
    data;  //Current byte being shifted

  crc = 0xFFFF; // Preset to all 1's, prevent loss of leading zeros

  while(count--)
    {
    data = *ptr++;

    for(i=0;i<8;i++)
      {
      if(((unsigned char)crc & 0x01) ^ (data & 0x01))
        crc = crc >> 1 ^ POLY;
      else
        crc >>= 1;
    
      data >>= 1;
      }
    }
  return (~crc);
  }
 

cjs

New member
compiled that code, much simpler thank you, but still returns the same result as the longer version i posted previously.....so, knowing that this crc code returns the proper crc.... here is how i'm sending the packet to the crc function. as i understand it, the packet length value sent to the lcd includes only the actual text and cursor positions...in this case packet_buffer[2]-->[7]....not the command or data length. the data length value sent to the crc function includes the command buffer as well as the data length value, packet_buffer[0]-[1]....once the crc function is done, the packet is then sent over serial with the crc value tacked onto the end of the data stream....could someone verify/correct this for me...

here is the code i'm currently working with:
PHP:
while(TRUE)                                  
   {
        packet_buffer[0] = 31;
        packet_buffer[1] = 6;
        packet_buffer[2] = 0;
        packet_buffer[3] = 0;
		packet_buffer[4] = 'S';
		packet_buffer[5] = 'M';
		packet_buffer[6] = 'O';
		packet_buffer[7] = 'K';
        send_packet(packet_buffer, 8);       
	}
   
} 

// SEND_PACKET
void send_packet(unsigned char* packet_ptr, int16 packet_length)
{
   int *ptr;
   int16 CRC,i;
   ptr = packet_ptr;                           

	//Generate CRC
	CRC = get_crc(ptr, packet_length;
	                          
	for(i=0; i<packet_length; i++)
	{ 
		putc(packet_ptr[i]);	//String/Serial --> Crystalfontz
	}
	putc((int16)(CRC));
   	putc((int16)(CRC>>8));	// send CRC
   
}
 

CF Tech

Administrator
To have a base line of working code, does something like this work:
Code:
putc(31);   //LCD
putc(22);   //length
putc(0);    //x
putc(0);    //y
putc('H');
putc('e');
putc('l');
putc('l');
putc('o');
putc(' ');
putc('W');
putc('o');
putc('r');
putc('l');
putc('d');
putc(' ');
putc(' ');
putc(' ');
putc(' ');
putc(' ');
putc(' ');
putc(' ');
putc(' ');
putc(' ');
putc(14);   //LSB CRC
putc(229);  //MSB CRC
 

CF Tech

Administrator
That sequence of bytes will display "Hello World" on line 1.

So there must be something more basic wrong. Wiring? Signal levels? Baud rate? Port not opened correctly?
 
USB LCD Displays - Graphic and Character LCDs with a Keypad

cjs

New member
it appears to be but my scope cannot do a trace capture. the baud was set @500 in order to more clearly see the hi/low transitions, when talking to the 635 it is set to 115200. i ordered another 635 which should arrive today, that should provide an explanation to this issue.
 
Top