• We recently switched our forum platform. If you experience any issues please email support@crystalfontz.com

Character set

starlon

New member
What character set do these LCDs (CFA635) use? I've tried two different sets and neither has the 1/4 character at 0x8b. One didn't have it at all. I'm trying to display/draw the LCD's memory on a GUI element.
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 

starlon

New member
This is sort of related to the character set so I won't open a new thread. I worked out how to create special characters, and I can read the cgram content. However, I was expecting 64 bytes for 8 special characters. I went ahead and displayed the 6 resulting characters. Attached is what I got. Am I just confused about cgram?

Edit: I reversed the output for each bit, and took a screenshot of the result. It looks closer to something, but I think they're mixed up somehow.

Edit 2: Looking closer.
 

Attachments

Last edited:

CF Tech

Administrator
Each special character only uses the 6 least significant bits. So each special character is composed of 8 bytes, or which only bits bits 5 through 0 are valid (0x00 to 0x3F). The MSb is on the left, the LSb is on the right. The first byte is the top line, the 8th byte is the bottom line.

Here is a sample array in C, for reference:
Code:
unsigned char
  CGRAM[64]={0, 8,12,14,15,14,12, 8,  //right arrow  
             0, 1, 3, 7,15, 7, 3, 1,  //left arrow  
             0, 4, 4,14,14,31,31, 0,  //up arrow  
             0,31,31,14,14, 4, 4, 0,  //down arrow  
             0, 0,14,31,31,31,14, 0,  //circle  
             0, 1, 3, 3, 6,22,28,12,  //check  
             0,17,27,14, 4,14,27,17,  //cancel    
             4,14,63, 4, 4,63,14, 4}; //Up/Dn Arrow
So you should get 64 bytes representing 8 characters.
 

starlon

New member
Ok, I figured all of that out. What I don't understand is why the cgram data read by command 10 (Read 8 bytes memory) is only 48 bytes (cgram is 64 bytes?). Also, they don't seem to be ordered right. I assumed the first 8 bytes of cgram represents character 0x00 -- second 8 bytes represents character 0x01, etc... This doesn't seem to be the case.

Edit: Attached is the 8 characters you provided rendered.

Edit: Nevermind. I'm a ditz. There's 64 bytes. lol
 

Attachments

Last edited:

CF Tech

Administrator
When I do command 10 readbacks on the module that has the CGRAM initialized as shown above:

(CGRAM Char 0)
command: aC=10(10 = Read LCD Memory),L=1,D="\064",CRC=0xEE6A
response: C=74(10 = Read LCD Memory),L=9,D="\064\000\008\012\014\015\014\012\008",CRC=0x7F9E

(CGRAM Char 1)
command: aC=10(10 = Read LCD Memory),L=1,D="\072",CRC=0x6222
response: C=74(10 = Read LCD Memory),L=9,D="\072\000\001\003\007\015\007\003\001",CRC=0xAF97

. . .

(CGRAM Char 7)
command: aC=10(10 = Read LCD Memory),L=1,D="\120",CRC=0x53A1
response: C=74(10 = Read LCD Memory),L=9,D="\120\004\014\063\004\004\063\014\004",CRC=0x2454

Those line up 1:1 . . . am I missing something?
 

starlon

New member
Damn, just edited my post. I'm not thinking straight. That's 64 bytes in cgram. I just need to fix my program to read them all.
 

starlon

New member
Oh, I printed that onto the LCD to see if the there was a mistake in the PDF. There wasn't. To me that font looks like it is missing a dot on the top end. It looks like it should go down diagonally one more bit. I just wanted to make double sure and I was wrong. The PDF's graph and the LCD's character are both the same, just like the one seen in the image.
 
Top