635 & ttl serial w/ PIC

cjs · Sep 4, 2008

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)

Heffo · Sep 4, 2008

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 · Sep 4, 2008

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 · Sep 4, 2008

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.

CF Tech · Sep 5, 2008

Heffo said:
. . . If you got the CRC wrong it should send an error packet. . . .

A packet is defined as having the correct CRC. The CFA-635 only responds to packets. So if you send a "packet" with the incorrect CRC, there will be no response.

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.

cjs · Sep 5, 2008

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....

cosmicvoid · Sep 5, 2008

cjs said:
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 · Sep 5, 2008

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 · Sep 5, 2008

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 · Sep 8, 2008

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 · Sep 8, 2008

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

cjs · Sep 8, 2008

no, that gives me nothing....

CF Tech · Sep 8, 2008

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?

cjs · Sep 9, 2008

here's a scope shot of the serial data @500baud set at 2.5v graduations....

CF Tech · Sep 12, 2008

This post:

https://forum.crystalfontz.com/showthread.php?p=24352#post24352

has an oscilloscope screen shot that shows communications wave forms should look like. Can you verify that this is the same kind of thing you are feeding the CFA-635?

The CFA-635 is set to 115200 by default. Did you take that into account?

cjs · Sep 15, 2008

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.

CF Tech · Sep 15, 2008

OK. Please keep us up to date. If the module is faulty, please write support@crystalfontz.com so we can sort it out.

cjs · Sep 15, 2008

bingo....hooked up the new unit and it displays "hello world"...

CF Tech · Sep 15, 2008

cjs said:
bingo....hooked up the new unit and it displays "hello world"...

OK, I am glad you have it going.

Support will take care of the other display in your ticket.

635 & ttl serial w/ PIC

New member

Attachments

New member

New member

New member

Administrator

New member

Master

New member

Administrator

New member

Administrator

New member

Administrator

New member

Attachments

Administrator

New member

Administrator

New member

Administrator