> I have several messages, more than 10, to be displayed on a 20 + 20
> LCD.  Sometimes more than one at a time i.e. "description" then a
> number.
> I have been laboriously writing a sub routine for each message, with 3
> lines per character:
>         (establish LCD screen address)
>         movlw   "M"
>         movwf   char
>         call    lcd             ;which writes the character to LCD
>         etc.
> This ends up being a couple of thousand lines of code!  Admittedly
> pretty easy to write - just copy and change the character.
>
> However, there's gotta be a better way!

There sure is.  My first reaction would be to store each string as data in
program memory, then write a generic subroutine that is passed the address
of the string and displays it.  The subroutine will also have to know the
string length.  This could be put automatically at the start of the string
with a little assembler cleverness, or you could use a terminating zero, or
some other scheme.

> A few messages could be stored
> in a table, but at present I only know how to store a table in the first
> 256 bytes.

You didn't say what PIC you are using, but generally only the 12 family has
this limitation, and even there it's the first 256 locations of each page.
Most of the F parts can read their own program memory directly, which will
allow you to store two 7-bit characters per word instead of just one 8-bit
byte using a RETLW instruction.

> Also, somewhere (and I can't find it again!) I thought I
> read where there can be a problem with tables accross a 256 boundary.

It is only a "problem" in that you have to pay attention to PCLATH.  A
better way of stating this is:  IF you can arrange your table not to cross a
256 address boundary, AND you really need the few extra cycles or code
space, THEN you can get away with not setting PCLATH.  Normally I do the
full address calculation including PCLATH unless cycles or code space are
really tight.  It's a lot more maintainable and less likely to be a source
of a bug.

> I think I've got to find out more about moving the Program Counter to a
> given point in program memory, reading a character there, and
> trensferring it either directly to the LCD or to a ram location for
> transfer to the LCD later, repeating for each character in the message.
> I don't ask for someone to sit and write me a complete "How to", but I'd
> appreciate a pointer to an article(s) somewhere on extensive tables, or
> PC manipulation especially accross pages.

My HAL project directly reads 7-bit WAV file data from program memory, which
is not that different from reading 7-bit characters.  See the HAL_INTR.ASPIC
module at http://www.embedinc.com/pic/hal.htm.  This also does some
interpolation between samples which you can ignore.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics