Searching \ for '[PIC]: LCD problems revisited' 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/io/lcd/pic.htm?key=lcd
Search entire site for: 'LCD problems revisited'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: LCD problems revisited'
2001\03\06@200120 by Ian Hynes

flavicon
face
PICers,
Uh, another dumb question!

Refer to the snippet from Myke Predko's 2 wire LCD interface routine.
Can anybody please explain *exactly* what he's doing with his movf
FSR,w/incf FSR/call message routine?

I don't see how it "knows" to get the proper ascii characters. I mean
I've stepped it thru and see it moving round the Outloop in proper
order - but it's a complete blank how it's getting the characters. I'm
trying to figure out how to pass ascii to it as parameters.


Message                         ;  Message to Output
 addwf  PCL                    ;  Output the Characters
 dt     "Hello", 0

SendCHAR
 movwf  Temp                   ;  Save the Temporary Value
 ... SNIP ....
 return

...SNIP ....

clrf    FSR                    ;  Output the Message

OutLoop
 movf   FSR, w                 ;  Get the Offset to Output
 incf   FSR
 call   Message
 iorlw  0                      ;  At the End of the Message?
 btfsc  STATUS, Z
  goto  Loop                   ;  Yes - Equal to Zero
 call   SendCHAR               ;  Output the ASCII Character
 goto   OutLoop



Thanx - Ian

PS: Man, I promise if ever I get a handle on this LCD stuff, I'll put
it all up on a web page for all to see. What little I know ...

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


2001\03\06@202834 by Wayne Hortensius

flavicon
face
At 11:57 AM 3/7/01 +1100, Ian Hynes <.....elekKILLspamspam@spam@NETSTRA.COM.AU> wrote:
>Refer to the snippet from Myke Predko's 2 wire LCD interface routine.
>Can anybody please explain *exactly* what he's doing with his movf
>FSR,w/incf FSR/call message routine?

FSR is used (I think) as a convenient register for the into the offset and
not how you might think it's supposed to be used. Try this:

       offset (fsr) = 0
Outloop
       get current offset (fsr)
       increment offset
       call Message       ; with offset in w, returning char in w
.                          ; stuff to check for end of message
.                          ; and output the returned character
.
.
Message
       add offset value to current PC ; i.e. jump to (PC+W)
;       dt     "Hello",0   ; which translates to....
       retlw 'H'          ; return 'H' when W is 0
       retlw 'E'          ; return 'E' when W is 1
       retlw 'L'          ; return 'L' when W is 2
       retlw 'L'          ; return 'L' when W is 3
       retlw 'O'          ; return 'O' when W is 4
       retlw 0            ; return 0 when W is 5

Hope that just didn't muddy the waters more!

Regards,
Wayne

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


2001\03\06@232320 by James Cameron

flavicon
face
On Wed, Mar 07, 2001 at 11:57:54AM +1100, Ian Hynes wrote:
> Refer to the snippet from Myke Predko's 2 wire LCD interface routine.
> Can anybody please explain *exactly* what he's doing with his movf
> FSR,w/incf FSR/call message routine?

Firstly, he's just using FSR as general purpose register.  Ignore the
fact for the moment that FSR is also used with INDF.  Myke isn't using
that feature of the register in his code that you quote.

> I don't see how it "knows" to get the proper ascii characters. I mean
> I've stepped it thru and see it moving round the Outloop in proper
> order - but it's a complete blank how it's getting the characters. I'm
> trying to figure out how to pass ascii to it as parameters.

Well, it calls the function at label Message repeatedly, first with
the W register set to zero, then with it set to one, etc.  The Message
function adds the W register to the PCL, thus causing a branch into
one of the "dt" bytes, which are actually RETLW instructions.

So, when Message is called first, it returns with 'H' in the W
register.  When it is called the next time it returns 'e', and so on.
This Message function is what we call a table.

Now, for a step by step explanation of the bit you pointed out ...

>  clrf    FSR                    ;  Output the Message

This might be better commented as "reset the offset into the message".
It sets the FSR register, which is used as an offset into the message.
If FSR is zero, then it is the 'H', and so on.

> OutLoop
>   movf   FSR, w                 ;  Get the Offset to Output

This loads the offset into the W register so that it can be used by
the table function Message.

>   incf   FSR

This increments the offset for next time around.  Without this, it
would scream along with lots of 'H' characters and would not move onto
the 'e'.

>   call   Message

This "translates" the offset into a character from the message, by
calling the table function.  The result is returned in the W register.

>   iorlw  0                      ;  At the End of the Message?

This is used to check if the returned value is zero.

>   btfsc  STATUS, Z
>    goto  Loop                   ;  Yes - Equal to Zero

If it was zero, the sending stops (it branches to a label Loop, which
you didn't show the code for).

>   call   SendCHAR               ;  Output the ASCII Character

If it was _not_ zero, then the SendCHAR function is used to send the
character that was returned by Message.

>   goto   OutLoop

Round and round until the zero is found.

> PS: Man, I promise if ever I get a handle on this LCD stuff, I'll put
> it all up on a web page for all to see. What little I know ...

That's the idea.  Had a look at mine?  I've just put up some really
nasty functions for handling tables.  http://quozl.netrek.org/

--
James Cameron    .....quozlKILLspamspam.....us.netrek.org     http://quozl.netrek.org/

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


2001\03\07@090515 by Olin Lathrop

face picon face
{Quote hidden}

<rant>This is another example of why poorly documented code is worse than no
code.  Think of all the collective time that has now been wasted as a
result.  I doubt any benefit from this code will be enough to make up the
difference.</rant>

He is using the value in FSR as an index into the "Hello" string.  The DT
directive in MESSAGE produces a set of RETLW instructions, one for each
character in the string.  The ADDWF PCL instruction jumps ahead by the value
in W.  MESSAGE therefore takes a 0-N character index in W in, and returns
with the indexed character in W - just like the header comments for MESSAGE
should have clearly explained.

I don't know anything about this guy other than the code shown here.  Given
that, I advise staying away from any of his stuff.  People who write bad
code in one respect also tend to write bad code in another.  At best this
points to a "I don't give a crap" attitude.  At worst ...


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\03\07@121350 by Bill Westfield

face picon face
   <rant>This is another example of why poorly documented code is worse
   than no code.  Think of all the collective time that has now been
   wasted as a result.  I doubt any benefit from this code will be enough
   to make up the difference.</rant>

I don't think much time was wasted.  Someone didn't understand it, a bunch
of people did and explained it.


   He is using the value in FSR as an index into the "Hello" string.  The
   DT directive in MESSAGE produces a set of RETLW instructions, one for
   each character in the string.  The ADDWF PCL instruction jumps ahead
   by the value in W.  MESSAGE therefore takes a 0-N character index in W
   in, and returns with the indexed character in W - just like the header
   comments for MESSAGE should have clearly explained.


This is VERY VERY standard string handling for a PIC, isn't it?  Even I
figured it out pretty quick.  The only "weird" bit was the use of FSR as a
general purpose counter in the OutLoop (which doesn't seem to be what
you're complaining about.)  You don't document all your C string functions
with comments that the strings are null-terminated, or every PIC subtact
with comments about the carry bit being backward...

BillW

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


2001\03\07@142555 by Drew Vassallo

picon face
> > Refer to the snippet from Myke Predko's 2 wire LCD interface routine.
> > Can anybody please explain *exactly* what he's doing with his movf
> > FSR,w/incf FSR/call message routine?
> > Message                         ;  Message to Output
> >   addwf  PCL                    ;  Output the Characters
> >   dt     "Hello", 0

>The ADDWF PCL instruction jumps ahead by the value
>in W.  MESSAGE therefore takes a 0-N character index in W in, and returns
>with the indexed character in W - just like the header comments for MESSAGE
>should have clearly explained.

Olin is brutal!  But I agree for the most part.  I comment almost every line
(jesus, it only takes a second), plus a nice little paragraph or so by each
routine to explain its purpose.  Why NOT do this??

BEWARE OF THIS METHOD OF TABLE ADDRESSING!  You'll note that his "Message"
table is located at ORG 0x000.  This is the only reason that this method
works.  If you locate your tables in another memory location, like after the
ISR (ORG 0x004), or if you have multiple tables, a better way for simple
indexing is:

Message
       addlw   -(Message+2)    ; adjust index before continuing
       addwf   PCL, 1
dt "Hello", 0

Of course, there is also the PCLATH concern, which Myke ignores here because
of the short table and memory placement.  For using this simple method of
addressing the table characters, you'll have to ensure that the table
doesn't cross a page boundary.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

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


2001\03\07@143358 by Bill Westfield

face picon face
   > > Message                         ;  Message to Output
   > >   addwf  PCL                    ;  Output the Characters
   > >   dt     "Hello", 0

   BEWARE OF THIS METHOD OF TABLE ADDRESSING!  You'll note that his
   "Message" table is located at ORG 0x000.  This is the only reason that
   this method works.  If you locate your tables in another memory
   location, like after the ISR (ORG 0x004), or if you have multiple
   tables, a better way for simple indexing is:
   Message
           addlw   -(Message+2)    ; adjust index before continuing
           addwf   PCL, 1
   dt "Hello", 0

huh?  How come?  It's adding to the PC, rather than moving to the PC.
Shouldn't that work anywhere (not counting PCLATH) ?

BillW

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


2001\03\07@144055 by Drew Vassallo

picon face
>BEWARE OF THIS METHOD OF TABLE ADDRESSING!  You'll note that his "Message"

DOH!!  More like: Beware of misinformation from the author!  I was thinking
of his 3-wire example code where he "combined" two tables into one, and
preloaded W with the location of the section he wanted to recall.  The
information I gave in this post is incorrect; the table is fine the way he
has it, and you can put it anywhere (with the caveat of page boundaries).

BUT, if you want to put two tables into one location, then the information I
gave was correct.  For example, preload W with Ptr_1 literal, call Message,
then preload W with Ptr_2 literal, call Message again.

>Message
>        addlw   -(Message+2)    ; adjust index before continuing
>        addwf   PCL, 1
>Ptr_1:
>dt "Hello", 0
>Ptr_2:
>dt "Hello again", 0

My deepest apologies for the confusion.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

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


2001\03\07@210802 by Olin Lathrop

face picon face
> This is VERY VERY standard string handling for a PIC, isn't it?  Even I
> figured it out pretty quick.  The only "weird" bit was the use of FSR as a
> general purpose counter in the OutLoop (which doesn't seem to be what
> you're complaining about.)  You don't document all your C string functions
> with comments that the strings are null-terminated, or every PIC subtact
> with comments about the carry bit being backward...

I don't mention the null terminator on C strings, but I do use my SKIP_WLE
and SKIP_WGT macros in part to make it easier to understand compares, but
that's not what I was complaining about either.  I thought the most blatant
omission was any documentation as to what the subroutine did from the
caller's point of view.  One shouldn't have to look at the code to figure
out what it does except in rare circumstances.  And yes, I *DO* put header
comments on all my subroutines that document this.  I also thought the
unusual use of FSR might have been worthy of a comment or two, and the fact
that the subroutine must not cross a 256 program memory address boundary.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinspamTakeThisOuTembedinc.com, http://www.embedinc.com

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


2001\03\07@210840 by Olin Lathrop

face picon face
> huh?  How come?  It's adding to the PC, rather than moving to the PC.
> Shouldn't that work anywhere (not counting PCLATH) ?

As long as the table doesn't cross a 256 block boundary.  A more robust way
to do this is to do a full add and propagate the carry into PCLATH.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, EraseMEolinspamembedinc.com, http://www.embedinc.com

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


2001\03\08@084046 by Bob Ammerman

picon face
----- Original Message -----
From: Olin Lathrop <RemoveMEolin_piclistspam_OUTspamKILLspamEMBEDINC.COM>
To: <RemoveMEPICLISTTakeThisOuTspamspamMITVMA.MIT.EDU>
Sent: Wednesday, March 07, 2001 6:49 PM
Subject: Re: [PIC]: LCD problems revisited


> > huh?  How come?  It's adding to the PC, rather than moving to the PC.
> > Shouldn't that work anywhere (not counting PCLATH) ?
>
> As long as the table doesn't cross a 256 block boundary.  A more robust
way
> to do this is to do a full add and propagate the carry into PCLATH.

I prefer _NOT_ to carry into PCLATH, especially for short tables. Instead, I
put 'guards' around the code to generate an assembler error if the table
spans a page boundary. It seldom does, and when it happens I usually just
shuffle the code around a bit to solve the problem.

I often explicitly place large tables on a page boundary with an ORG.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@093327 by Olin Lathrop

face picon face
> I prefer _NOT_ to carry into PCLATH, especially for short tables. Instead,
I
> put 'guards' around the code to generate an assembler error if the table
> spans a page boundary. It seldom does, and when it happens I usually just
> shuffle the code around a bit to solve the problem.
>
> I often explicitly place large tables on a page boundary with an ORG.

Sounds reasonable enough.  However note that this method isn't available if
using the linker.

I use the linker and diddle PCLATH.  The extra few instructions and cycles
are usually insignificant in the scheme of things and are usually well worth
the maintainability.  In dozens of PIC projects I can only remember one case
off the top of my head where speed was critical.  I was doing a table lookup
in the interrupt routine, so I used the CODE directive to start the table at
the last 256 word block in code page 0.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, EraseMEolinspamspamspamBeGoneembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@104021 by Scott Dattalo

face
flavicon
face
On Thu, 8 Mar 2001, Olin Lathrop wrote:

> > I prefer _NOT_ to carry into PCLATH, especially for short tables. Instead,
> I
> > put 'guards' around the code to generate an assembler error if the table
> > spans a page boundary. It seldom does, and when it happens I usually just
> > shuffle the code around a bit to solve the problem.
> >
> > I often explicitly place large tables on a page boundary with an ORG.
>
> Sounds reasonable enough.  However note that this method isn't available if
> using the linker.

Actually, it becomes quite unreasonable in practice (my practice that is). I
agree with you (Olin) that dinking with PCLATH is a good trade off in speed vs
maintainability. Since we're talking about comments/lcd string stuff, here's
mine (which can be found http://www.dattalo.com/gnupic/lcd.html in the gpsim
module lcd-0.1.1.tar.gz):

;*******************************************************************
;write_string
;
;  The purpose of this routine is to display a string on the LCD module.
;On entry, W contains the string number to be displayed. The current cursor
;location is the destination of the output.
;  This routine can be located anywhere in the code space and may be
;larger than 256 bytes.
;
; psuedo code:
;
; char *string0 = "foo";
; char *string1 = "bar";
;
; char *strings[] = { string0, string1};
; char num_strings = sizeof(strings)/sizeof(char *);
;
; void write_string(char string_num)
; {
;   char *str;
;
;   str = strings[string_num % num_strings];
;
;   for( ; *str; str++)
;     LCD_WRITE_DATA(*str);
;
; }
;
; Memory used
;    buffer2, buffer3
; Calls
;    LCD_WRITE_DATA
; Inputs
;    W = String Number
;


This is just the comments for the header. I agree with Myke's commenting
philosophy of not over commenting the individual pic instructions. Instead, a
verbose description up front helps describe the intention well enough that
during debugging I often don't need to probe into the details.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


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