Suggestion on table lookup for LCD display

[dmarciano]

I'm going to be using a Hantronix LCD in a project and this requires sending each column of pixels one at a time. I was planning on using a lookup table to send each letter or word. However this is my first time using lookup tables so I'm hoping someone can provide a suggestion. This code is simplified and was designed to help me learn lookups. Basically this code should read the hex code for the letter 'H'. After loading each byte the code jumps to a section which will actually send it to the LCD and then continue the loop. Once it has read all the data it should loop back to 'Start' (at least in this test version)

Start	movwf	tt,0
		movlw	low(H_CHAR)
		addwf	tt,0,0
		movwf	TBLPTRL,0
		movlw	high(H_CHAR)
		movwf	TBLPTRU,0
lpl		tblrd	*+
		movlw	.153
		CPFSLT	TABLAT
		GOTO	Start
		GOTO	Send
		
Send	movf	TABLAT,0,0
		movwf	PORTA
		GOTO	lpl

H_CHAR	db	0x00,0xfe
        db  0x10,0x10
		db  0xfe,0x99

Select All

My problem is figuring out when it has read all the data. I was think of using 0x99 but realized I can't because if I wanted to enable all the pixels in a single column that would be 0xFF which is the highest, and if I wanted a column with no pixels on I would need to send 0x00, so any number in between these two values is possible.

What is a good way so determine when I have read all the data in the 'H_CHAR' table (in this example)? The 0x99 is not part of the actual data being sent to the LCD screen. After reading the last 0xFE and jumping to 'Send', when it returns to the 'lpl' loop the code should somehow be able to figure out/know that all the data was read.

This table is only 5 bytes, but some may be more and some may be less so it would help to have a single way of detecting this. Any help would be greatly appreciated. The application note for the LCD I'll be using can be found here and on the last few pages it give a sample code, albeit the code is in 8051 assembly which I'm not familiar with.

[ErnieM]

I did a display similar to this a few years ago. Character bit patterns were handled as simple uniform sized bitmaps, so all you need do is know the character size and the character code you want and you can compute an offset into an array.

I did spend much time on this and while I had a nice library of functions, I've abandoned that effort after finding simple black & white displays are not substantially cheaper then color displays.

I now just use the color ones and the excellent, free graphics object library from Microchip.

[dmarciano]

On Microchips website the graphics library is listed as only working with PIC24/dsPIC and PIC32, while I'm using the PIC18F46K22. I already have this chip and the Hantronix screen so I'd rather stick with them since they are sufficient for what I'm doing and I already have them in hand.

I'm not sure exactly what you mean by using sized bitmaps along with any array to display character on the Hantronix screen. This is the first time I'm using an LCD screen so maybe I'm missing something. Do you have an resources that you could point me to that will explain how to use your way, or the way I was trying to do it, for the type of application I'm working on.

Every time I try to Google table lookups they are about changing programming memory or the user has a special code at the end of the table they can check for; which I can't do for the reasons already stated. Is there a function for returning the size or element count of a lookup table?

[Markd77]

What I've done in the past is make the first byte of each array the length.

[ErnieM]

I make fonts from bitmaps of the same size placed into an array and padded out do each character starts on an even byte field. I used this structure for fonts:

typedef struct
{
    rom char FirstFont;            // first ASCII symbol defined
    rom char LastFont;            // last ASCII symbol defined
    rom char DefaultFont;        // If nothing available...
    rom char FontWidth;         // font width in pixels
    rom char FontHeight;        // font height in pixels
    rom char BytesPerCharacter;    // bytecount for a single character
    rom char *Bitmap;             // first byte of ROM bitmap 
} font;

Select All

Then a font file would look like so:

rom char Font5x7bits[] = {
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00,        // Space    32
    0x00, 0x00, 0x4F, 0x00, 0x00, 0x00,        // !        33
    0x00, 0x07, 0x00, 0x07, 0x00, 0x00,        // "        34
...
...
    0x00, 0x01, 0x02, 0x04, 0x00, 0x00,        // `        96
    0x7F, 0x41, 0x41, 0x41, 0x7F, 0x00        // (box)    97
};

rom font _Font5x7 = 
{
      32,        // first ASCII symbol defined
      97,        // last ASCII symbol defined
      97,        // If nothing available...
      6,         // font width in pixels
      8,         // font height in pixels
      6,        // 6 bytes in each character definition
      Font5x7bits
};

Select All

Obviously there are a bunch of routines behind this, and the bad news is since this is an abandoned work whatever documentation existed was never completed and pretty much lost. I think I did a brief explanation of the GLCD functions but that's gone. I also did a VB applet to take B&W bitmaps and convert to C style byte arrays, that's also gone.

I do have one of the last projects I did and I've included it in case you wish to reverse engineer some of it.

[nigelwright7557]

I have always used the same number of bytes for each character.