Searching \ for '[PIC]: Using large table to store/display graphics' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=table
Search entire site for: 'Using large table to store/display graphics'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Using large table to store/display graphics'
2001\04\25@043938 by Tim Thompson

flavicon
face
OK being farily new to PIC's in general this is probably a simple fix..

I'm working on a project that uses a PIC16F877 to interface a t6963c based
240x64 graphics
LCD display, and I'm trying to store a startup-screen in a table and have
the PIC send this data
to the LCD.
The table code is a modifyed version of the 'Big Table lookups' code in the
piclist
code repository.
The problem is the display shows a few 'random' pixels here and there, nothing
what the picture is supposed to be of, and the the PIC stops responding.

If anyone would be willing to look at the code it is at the bottom of the
email, but due to the
large table size, the table itself has been removed from this email.

the un-modifyed version can be gotten at:
http://www.irule.net/projects/carlcd/logo.asm.

Any help would be greatly apreciated!

Thanks in advance,
Tim Thompson


Start_Logo   clrf OffsetH
            clrf OffsetL

       LONG_CALL lcd_home_graph                ; Home graphics..
       LONG_CALL LogoLoop                      ; Start writing data from table
       return

LogoLoop
       movlw High(Table)
       movwf PCLATH
       call Table              ; get logo data

       movwf DATABUFA          ; move it to BUFA
       movlw DATA_WR_INC       ; Data write, incrament address
       movwf COMMANDBUF
       LONG_CALL lcd_send_1data_cmd    ; Send it

       movlw High(here)
       movwf PCLATH    ; reset PCLATH

here    incf OffsetL,F          ; add 1 to data pointer
       btfsc STATUS,C
       incf OffsetH,F

NoUp    movlw Low(d'2560')      ; 2560 bytes (240*64/6 (pixels per byte))
       xorwf OffsetL,W
       btfss STATUS,Z
       goto LogoLoop

       movlw High(d'2560')
       xorwf OffsetH,W
       btfss STATUS,Z
       goto LogoLoop
       return

Table   movlw High(TStart)
       movwf PCLATH
       movf OffsetH,W
       addwf PCLATH,F
       movlw Low(TStart)
       addwf OffsetL,W
       btfsc STATUS,C
       incf PCLATH,F
       movf OffsetL,W

DoTable addwf PCL, F
TStart
       <dt lines go here>


-
Remember, 'kill' doesn't kill processes, users kill processes.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\04\25@133639 by David Cary

flavicon
face
Dear Tim Thompson,

Tim Thompson <.....iruleKILLspamspam@spam@IRULE.NET> on 2001-04-25 03:31:07 AM begged for help:
...
> this is probably a simple fix.

Yep. One instruction.

...
> uses a PIC16F877 to interface
> a t6963c based 240x64 graphics LCD display

Does it really display 6 pixels per byte ?

...
> The table code is a modifyed version of the
> 'Big Table lookups' code in the piclist code repository.
> The problem is
> the display shows a few 'random' pixels here and there, nothing
> what the picture is supposed to be of, and the the PIC stops responding.
...
> http://www.irule.net/projects/carlcd/logo.asm
...
> Table   movlw High(TStart)
...
>         movlw Low(TStart)
>         addwf OffsetL,W
>         btfsc STATUS,C
>         incf PCLATH,F
>         movf OffsetL,W
>
> DoTable addwf PCL, F
> TStart
>         <dt lines go here>

Yep, simple fix. You're adding the Lo byte of the address of the table twice.
That last "add" needs to be a "mov".

    ; warning: untested code.
Table:
       movlw High(TStart)
       movwf PCLATH
       movf OffsetH,W
       addwf PCLATH,F
       movlw Low(TStart)
       addwf OffsetL,W
       btfsc STATUS,C
       incf PCLATH,F
       movf OffsetL,W
       movwf PCL

    ; OK to put more code here
    nop
    ...
    nop
    nop

TStart
    dt 0x00
     ; more dt lines go here
    ...

That should fix it, but let me ramble on a bit.

So, do you have any code to handle proportional fonts yet ?

I've simplified my table lookup code even further so it just directly jumps to
the address in OffsetH,OffsetL (rather than adding that offset to TStart). That
means that my loop code has to initialize OffsetH:OffsetL to Tstart, and loops
until I reach (TStart + 240*64/6) == OffsetH:OffsetL.

This has the advantage of letting me use *same* ``lookup'' subroutine for
several different tables --
a big startup screen, a font table, and another font table with large numbers. I
don't need 3 different copies of this subroutines, where the only difference
would be "TStart" replaced with "FontStart" or "BigNumberFontStart".

; Jump to address in look_hi/look_lo, which presumably is an RETLW.
; Note pointer post increment.
; Equivalent to: W=*look_ptr++
; from www.piclist.com/techref/microchip/tables.htm
; Handles tables of any size located anywhere in program FLASH.
; (256 byte tables don't work if you merely do ``addwf PCL,f'').
; And I want to handle
; at least 96 characters/table * 12 bytes/character = 1 152 bytes/table = 0x480
bytes/table.
; [FIXME: might be improved by
; www.piclist.com/techref/microchip/tables.htm
; tells how to read and write all 14 bits of a program memory location.
; ]
; http://piclist.com/techref/microchip/bigtable.htm

lookup:
               movf look_hi,w          ; set PCLATH
               movwf PCLATH
               movf look_lo,w          ; and get PCL
               incf look_lo,f          ; but post inc
               skpnz
               incf look_hi,f
               movwf PCL               ; ok, now jump
               ; return

; lookupTOS:
; 2001-04-18:DAV: wrote lookupTOS() based on lookup()
; same as lookup, but uses a 16 bit value on the stack.
; Leaves the incremented value on stack, with result in w.
lookupTOS: ; ( lsB1 MSB1 count -- lsB3 MSB3 count ) where MSB3:lsB3 = (MSB1:lsB1
+ 1).
         pop  ; leave 8 bit ``count'' alone, increment the 16 bit value under
it.
         peekw          ; set PCLATH with MSB
         movwf PCLATH
         pop
         peekw     ; get PCL
         incf TOS,f     ; post increment
         push ; return to MSB without affecting Z
         skpnz
         incf TOS,f
         push ; leave stack the way we found it.
         movwf PCL ; OK, now jump
         ; return

--
David Cary

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\04\25@170416 by myke predko

flavicon
face
David,

Maybe I'm missing something in your answer, but in your code:

{Quote hidden}

You are:

1) setting PCLATH = High 8 Bits of TStart
2) Adding the High 8 Bits of the Offset to PCLATH
3) Adding the Low 8 Bits of TStart to the Low 8 Bits of the Offset
4) If Operation 3) sets the carry flag increment the PCLATH Register
5) Load PCL with the Low Offset

In this code, the results of 3) are lost.


I *think* the most efficient way of implementing this function would be:

Table:
;  PCLATH = HIGH(TStart + Offset)
       movlw High(TStart)
       addwf OffsetH,W
       movwf PCLATH
;  w = LOW(TStart + Offset)
       movlw Low(TStart)
       addwf OffsetL,W
;  if ((LOW(TStart) + LOW(Offset)) > 255) then PCLATH = PCLATH + 1
       btfsc STATUS,C
        incf PCLATH,F
;  PCL = w: PC = PCLATH/PCL
       movwf PCL

This is the code that I use for implementing large tables.

myke

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\04\25@192318 by David Cary

flavicon
face
You're right, Myke. The ``Table'' code I posted still wasn't quite right. Thanks
for fixing it.

---
myke predko <EraseMEmykespam_OUTspamTakeThisOuTPASSPORT.CA> on 2001-04-25 04:00:20 PM wrote:
I *think* the most efficient way of implementing this function would be:

Table:
;  PCLATH = HIGH(TStart + Offset)
    movlw High(TStart)
    addwf OffsetH,W
    movwf PCLATH
;  w = LOW(TStart + Offset)
    movlw Low(TStart)
    addwf OffsetL,W
;  if ((LOW(TStart) + LOW(Offset)) > 255) then PCLATH = PCLATH + 1
    btfsc STATUS,C
    incf PCLATH,F
;  PCL = w: PC = PCLATH/PCL
    movwf PCL

This is the code that I use for implementing large tables.

myke
---

Good job optimizing. I don't see any way to make this function ``Table'', in
isolation, faster or smaller. Mind if this gets stuck on http://piclist.com as
public domain ?

However, I don't plan on using it. All my code uses something similar to
``lookup'':

; Jump to address in look_hi/look_lo, which presumably is an RETLW.
; Note pointer post increment.
; Equivalent to: W=*look_ptr++
; Handles tables of any size located anywhere in program FLASH.
; (256 byte tables don't work if you merely do ``addwf PCL,f'').
; [FIXME: might be improved by
; www.piclist.com/techref/microchip/tables.htm
; tells how to read and write all 14 bits of a program memory location.
; ]
; piclist.com/techref/microchip/bigtable.htm
lookup:
               movf look_hi,w          ; set PCLATH
               movwf PCLATH
               movf look_lo,w          ; and get PCL
               incf look_lo,f          ; but post inc
               skpnz
               incf look_hi,f
               movwf PCL               ; ok, now jump

which has the benefit of only requiring 1 subroutine for all the various tables
I use (rather than a separate copy for each table, like `Table' does). The code
that *calls* ``lookup'' needs to set up the loop with a couple more instructions
than if I had used ``table'', but overall it's a win ROM-space-wise and, I
think, time-wise.

I've got another version working that, rather than look_hi:look_lo, uses
whatever register pair FSR points toward. It's a little slower than ``lookup''
or ``table'', but I think it might turn out to be a win (overall) space-wise.

--
David Cary

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\04\26@032920 by Tim Thompson

flavicon
face
Thank-you both for your help! Myke's code seems to work fine, though i
didnt get around to trying Davids..
but the LCD still isnt displaying the right data..anyone have a
windoze/Linux program that will read in a bitmap
and convert it to useable data? Mind you the LCD takes six-bit bytes (its
in 6x8 font, as aposed to 8x8 font,
so a full charictor is 6 bits wide, which is a standard mode for the t6963c
controller based graphical LCDs..) so that will have to be taken into
acount..

I have tryed BMP2ASM by John G..but it apears to output the data in
possibly individual bits..or something
..remver im a novice at best :P

Thanks again and in advance,
Tim Thompson

At 06:21 PM 4/25/2001 -0500, you wrote:
>You're right, Myke. The ``Table'' code I posted still wasn't quite right.
Thanks
{Quote hidden}

http://piclist.com as
{Quote hidden}

tables
>I use (rather than a separate copy for each table, like `Table' does). The
code
>that *calls* ``lookup'' needs to set up the loop with a couple more
instructions
>than if I had used ``table'', but overall it's a win ROM-space-wise and, I
>think, time-wise.
>
>I've got another version working that, rather than look_hi:look_lo, uses
>whatever register pair FSR points toward. It's a little slower than
``lookup''
{Quote hidden}

Remember, 'kill' doesn't kill processes, users kill processes.

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\04\26@050053 by Graham Harrison

flavicon
picon face
I have a Windows application that takes a 240 X 128 bmp file and converts it
into a hex file of 6 bit graphics bytes. This can be blown into an eprom and
a PIC used to clock it out to an LCD with a 6963 controller. The method is
described at http://www.redwinter.freeserve.co.uk/lcdif.htm. Also a similar piece
of software for converting text files to LCD ascii format (minus 30) for
similar storage in eprom. Using this method you can store 128 pages of text,
each 256 characters long in a 27C256, or 8 full graphics pages

Regards

Graham Harrison

{Original Message removed}

2001\04\26@101712 by David Cary

flavicon
face
Dear Tim Thompson,

Tim Thompson <spamBeGoneirulespamBeGonespamIRULE.NET> on 2001-04-26 02:29:29 AM thanked Myke and David
for the help, then asked:
...
>anyone have a
>windoze/Linux program that will read in a bitmap
>and convert it to useable data? Mind you the LCD takes six-bit bytes (its
>in 6x8 font, as aposed to 8x8 font,
>so a full charictor is 6 bits wide, which is a standard mode for the t6963c
>controller based graphical LCDs..) so that will have to be taken into
>acount..
...
Tim Thompson

Ever heard of
 http://www.piclist.com
?

I'm really impressed with the character set generator program by Nikolai
Golovchenko. I downloaded the source code and a precompiled executable and a
pre-processed font. The program lets you choose whether to take your font bitmap
and convert it to 1 byte per row (simplest to decode) or try to pack it denser
and squeeze 3 rows / 2 bytes. It's a classic time/space tradeoff.

Check out the fonts at
piclist.org/techref/datafile/charsets.htm
http://piclist.org/techref/datafile/charset/extractor/charset_extractor.htm

Um... you probably want a 1 pixel gap between your letters on the screen, so
maybe you want the 7x5 font there.

I'm trying to write a little code that does *proportional* fonts (each letter in
the font has an extra byte (extra 4 bits ?) that specifies exactly how many
pixels wide it really is). The program shifts the pixels from the font table
back and forth and combines them with the previous and next letter. As a side
effect, this makes it easier to make a font of any arbitrary width, and place
letters *anywhere* on the screen (rather than X locations that are multiples of
6 pixels).

But it's not working yet :-(.

Later I'll try to modify Golovchenko's program to automatically calculate the
"width" of each letter.

--
David Cary

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...