HI all, I am doing the same thing as Howard. I am currently use the PIC16F877 and it's quite a pain and memory wasting to write the codes for the LCD. I am wondering, if there is a "c like" code that I can just do: dt "This is LCD Line 1" dt "This is LCD Line 2" call Display_LCD ; now the LCD displays: ; This is LCD Line 1 ; This is LCD Line 2 dt "Test line 1" dt "Test line 2" call Display_LCD ; now the LCD displays: ; Test line 1 ; Test line 2 Am I asking for too much? Best regards, Thomas >From: Olin Lathrop >Reply-To: pic microcontroller discussion list >To: PICLIST@MITVMA.MIT.EDU >Subject: Re: [PIC]:LCD character >Date: Sun, 2 Jun 2002 19:12:54 -0700 > > > 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 _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. -- 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