Searching \ for '[PIC]: LCD String function' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/io/lcd/pic.htm?key=lcd
Search entire site for: 'LCD String function'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: LCD String function'
2003\10\26@174911 by Thomas N

2003\10\26@180154 by Mauricio Jancic

2003\10\26@191818 by cdb

This is what I use.

The WHILE(*tmpPtr) loop will send out each character one by one until
it hits the null character. If your compiler doesn't null terminate
strings you'll need to add it yourself.

Ignore the first rs=0, I always put the display position as the first
part of the string. Just leave this bit out if you don't.



This should work with no alteration in the 18F series.

If you don't like this method, then you can download Maestro from
Microchips site and it will produce a file ready for using.

Colin

void display(unsigned char *tmpPtr)
{

 unsigned char currentCH;

 rs=0;                                 //RS in Command mode for position byte

 #ifdef TOP
 while(*tmpPtr)                //LCD Data on bits D4-D7 of PORT
   {

       currentCH=*tmpPtr;
       LCDPORT&=0x0F;
       LCDPORT=(currentCH&0xF0);       //Mask off upper nibble
       sendit(rs);
       currentCH<<=4;                          //Now select lower nibble
       LCDPORT=currentCH;
       sendit(rs);
       t40();
       rs=1;                                           //make sure RS is in data mode
       tmpPtr++;                                       //get next character

}

On Sun, 26 Oct 2003 14:48:48 -0800, Thomas N wrote:
::lcd_puts("hello world");    // prints "hello world" on the LCD
::
::I am currently using C18 compiler with 18F452 micro.

--
cdb, spam_OUTbodgy1TakeThisOuToptusnet.com.au on 27-October-2003

I have always been a few Dendrites short of an Axon and believe me it
shows.

Light travels faster than sound. That's why some people appear bright
until they speak!

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\10\26@205001 by Thomas N

Thank you for your help!  Your function will accept something like:
lcd_puts(&somestring);
but not
lcd_puts("hello");

Is there a way to change the function so that it accept a string on the fly ("hello") instead of a predefined string?

Sorry for my lack of C skills.
Regards,
Thomas
Mauricio Jancic <.....jancicKILLspam@spam@ARNET.COM.AR> wrote:
This one works fine for me:


void
lcd_puts(const char * s)
{
LCD_RS = 1;
while(*s)
{
lcd_putch(*s++);
}
}

Best regards

Mauricio Jancic
Janso Desarrollos
Microchip Consultant
(54) - 11 - 4542 - 3519

{Original Message removed}

2003\10\26@235833 by Ishaan Dalal

2003\10\27@001749 by Thomas N

Yes, I get the idea, but I have a hard time to implement it.

Ishaan Dalal <izxKILLspamXIZX.NET> wrote:I haven't played with C18 at all, but wouldn't iterating through the
string=char array and using lcd_putc() do the job?

Cheers,
Ishaan

{Original Message removed}

2003\10\27@014854 by Wouter van Ooijen

> I want to write another lcd_puts() function (which uses
> lcd_putc() function) to send a _string_ to the LCD, but I
> don't know how to do it.  I would like to write:

check the XLCD module, both the bare LCD routines and string write
routines (different ones for variables and constatnt strings) are there.

I use:

void LCD_Const_Write( const rom char * Buffer ){
  while( *Buffer ){
     LCD_Char_Write( *Buffer );
     Buffer++;
  }
}

void LCD_Var_Write( char * Buffer ){
  while( *Buffer ){
     LCD_Char_Write( *Buffer );
     Buffer++;
  }
}

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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

2003\10\27@021634 by piclist

On Mon, 27 Oct 2003, Wouter van Ooijen wrote:

> void LCD_Const_Write( const rom char * Buffer ){

> void LCD_Var_Write( char * Buffer ){

Does C18 really force you to have two copies of any routine that deals
with strings?  How does it handle standard library functions like
strcpy?

--
John W. Temples, III

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

2003\10\27@065831 by Mauricio Jancic

2003\10\27@071322 by Wouter van Ooijen

> Cons unsigned char      str1 = "String number 1";
> unsigned char           str2 = "String number 2";
>
>
> Lcd_puts(str1);
> Lcd_puts(str2);
> Lcd_puts("String Number 3");

Did you try that on C18? And did you try

cons rom char * str3 = "String number 3";
Lcd_puts(str3);

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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

2003\10\27@073221 by Mauricio Jancic

2003\10\27@075955 by Wouter van Ooijen

> No, havent tryed that, whats the diference betwen
>
> Cons unsigned char      str1 = "String number 1";
> const rom char * str3 = "String number 3";
>
> Isn't suposed that werever you put const the dta will be stored on the
> ROM? Or I'm confusing compilers?

AFAIK a const qualifier has some consequences in the area of
assignability, but a compiler is not required to put the data in a
certain area. The probelm with PICs is that ROM and RAM are separate
address spaces, so a 'generalised' pointer (that can point to both
areas) would require more complex code when it is used. For the C18
compiler uChip instead choose to introduce the 'rom' qualifier to force
stoting in ROM. A consequence is that a declaration with 'rom' behaves
(internally) quite different from one without. Note that using a 'rom'
pointer looks the same as using a RAM pointer, but the generated code is
very different.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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

2003\10\27@082036 by Hulatt, Jon

2003\10\27@082908 by Mauricio Jancic

2003\10\27@085029 by Mauricio Jancic

>>I may be way off the mark here because I've never used C18, however,
these examples are either bad or wrong.
>>In C, a "char" is a single character, and normally one byte. A string
is an array of char .
>>Therefore,
>>const char str1 = "hello world";
>>is either illegal, or, depending on how the compiler handles it, might
well be the same as saying
>>const char str1 = 'h';
>>What you actually want to do is say:-
>>const char[] str1 = "hello world";

Yes, just a typo mistake

>>Additionally,
>>
>>const char * str3 = "hello world";

That's what I mean to say....

>>is also either illegal, or in some compilers will produce not quite
the effect you're looking for. It would potentially create a char
pointer, which is preconfigured to point to whatever value is
represented by that string. In Win32, pointers are 32 bit, so that would
(in visual c++) create a const char pointer that points to a memory
address of "hell" (0x68656C6C), which is an Access Violation /
Protection fault waiting to happen.

Yes...
>>Additionally, remember that a "const char *" is a pointer whose value
(ie what it points to) is fixed, however, you can (normally) write to
the address  pointed to by the pointer. eg:-
>>
>>const char * c = 0x70
>>
>>*c = 'A' ; // valid-> 0x70 now contains 'A'
>>c = &otherchar ; // invalid. c is const.


Well, you are right. I didn't see that, while I actually know it....
Dammm! BUT, I did a test. My compiler says, after compiling that I'm
using 168 bytes of RAM, so I comented a long list of strings (12 screens
for a 20x4 display) defined like:

const char * str3 = "hello world";

And nothing changed on the RAM area. Look at the compiler results..:

With all the screens:

Program ROM   $000000 - $000003  $000004 (       4) bytes Program ROM   $000008 - $000013  $00000C (      12) bytes Program ROM   $000018 - $00006F  $000058 (      88) bytes Program ROM   $0000CA - $0005FD  $000534 (    1332) bytes Program ROM   $000D6C - $003B57  $002DEC (   11756) bytes
                                $003388 (   13192) bytes total Program
ROM

RAM data      $000092 - $0000FF  $00006E (     110) bytes RAM data      $0005CF - $0005FF  $000031 (      49) bytes
                                $00009F (     159) bytes total RAM data

Near RAM      $000000 - $000007  $000008 (       8) bytes total Near RAM

Near bits     $000040 - $000043  $000004 (       4) bits  total Near
bits    
ROM data      $000070 - $0000C8  $000059 (      89) bytes ROM data      $000600 - $000D6A  $00076B (    1899) bytes                                   $0007C4 (    1988) bytes total ROM data


Program statistics:  
Total ROM used    15180 bytes (46.3%) Total RAM used      168 bytes (10.9%)   Near RAM used        9 bytes (7.0%)

Now, without the screens... (12 screens * 20 chars * 4 lines = 960
bytes)

Memory Usage Map:  Program ROM   $000000 - $000003  $000004 (       4) bytes Program ROM   $00008 -  $000013  $00000C (      12) bytes Program ROM   $000018 - $00006F  $000058 (      88) bytes  Program ROM   $0000CA - $0005FD  $000534 (    1332) bytes Program ROM   $000A02 - $0037ED  $002DEC (   11756) bytes
                                 $003388 (   13192) bytes total Program
ROM  
RAM data      $000092 - $0000FF  $00006E (     110) bytes RAM data      $0005CF - $0005FF  $000031 (      49) bytes
                                $00009F (     159) bytes total RAM data


Near RAM      $000000 - $000007  $000008 (       8) bytes total Near RAM

Near bits     $000040 - $000043  $000004 (       4) bits  total Near
bits    
ROM data      $000070 - $0000C8  $000059 (      89) bytes ROM data      $000600 - $000A01  $000402 (    1026) bytes                                   $00045B (    1115) bytes total ROM data


Program statistics:  
Total ROM used    14307 bytes (43.7%) Total RAM used      168 bytes (10.9%)   Near RAM used        9 bytes (7.0%)
So, as you can see ther is a difference (873 bytes, don’t know where are
the other 87 bytes to complete the 12 screens...:(

But the important thing is that the difference is on the ROM area and
not in RAM...

>>Hope that ramble helps :)

Yes, it does...

BST RGRDS

Mauricio


-- Outgoing mail is certified Virus Free.
Checked by AVG Anti-Virus (http://www.grisoft.com).
Version: 7.0.193 / Virus Database: 260.2.2 - Release Date: 27/10/2003

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

2003\10\27@091945 by Hulatt, Jon

>> Well, you are right. I didn't see that, while I actually know it....
Dammm! BUT, I did a test. My compiler says, after compiling that I'm using
168 bytes of RAM, so I comented a long list of strings (12 screens for a
20x4 display) defined like:

>> const char * str3 = "hello world";

>> And nothing changed on the RAM area. Look at the compiler results..:

Yep, it's not ANSI C, so what a compiler  implementer chooses to do with
that is unpredictable. IMHO it's a Wholly Bad Idea, and you should use one
of the other methods described in my post.

Jon

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

2003\10\27@115852 by piclist

On Mon, 27 Oct 2003, Hulatt, Jon wrote:

> const char[] str1 = "hello world";
>
> This will create str1 as a pointer to the first element of an array
> preinitialised to contain that string, and null terminated.

This creates a const array, not a pointer.

> const char * str3 = "hello world";
>
> is also either illegal, or in some compilers will produce not quite the
> effect you're looking for.

That is perfectly legal code.  It creates a pointer to the string
"hello world".  The only thing in the above code that might depend on
the compiler is whether "hello world" is in ROM or RAM.

> It would potentially create a char pointer, which
> is preconfigured to point to whatever value is represented by that string.

It points to the string, not the "value represented by that string."

> In Win32, pointers are 32 bit, so that would (in visual c++) create a const
> char pointer that points to a memory address of "hell" (0x68656C6C), which
> is an Access Violation / Protection fault waiting to happen.

I don't have access to VC++, but I think if you tried the above code
you would find it does nothing of the sort.

--
John W. Temples, III

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

2003\10\27@120724 by piclist

On Mon, 27 Oct 2003, Mauricio Jancic wrote:

> Dammm! BUT, I did a test. My compiler says, after compiling that I'm
> using 168 bytes of RAM, so I comented a long list of strings (12 screens
> for a 20x4 display) defined like:
>
> const char * str3 = "hello world";
>
> And nothing changed on the RAM area. Look at the compiler results..:

If you were able to comment them out, that meant that you weren't
referring to them in your code, so the compiler could have optimized
out the pointer.  Note that in your declaration, "hello world" will be
in ROM, and the pointer str3 will be in RAM.

--
John W. Temples, III

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

2003\10\27@123804 by Mauricio Jancic

2003\10\27@125100 by Peter L. Peres

solution 1: consumes stack for subroutine call:

void lcd_puts(char *s)
{
       char t;

       while((t = *s++))
               lcd_putc(t);
}

solution 2: no stack (inline function), may not work on some compilers:

#define lcd_puts(s) { while(*s) lcd_putc(*s++); }

There are usually two puts functions on a pic because the code is
different if s is in ram or in rom (pis are hardward machines).

Peter

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

2003\10\27@130726 by piclist

On Mon, 27 Oct 2003, Mauricio Jancic wrote:

> Const char      screen[][] = {
>                                 {"Hello 1"},
>                                 {"Hello 1"},
>                                 {"Hello 1"},
>                                 {"Hello 1"}
>                              }

That declaration is very different from this one:

> > I comented a long list of strings (12
> > screens for a 20x4 display) defined like:
> >
> > const char * str3 = "hello world";

in that the first one declares an array which can be entirely placed
in ROM, while the second one declares a pointer in RAM and a string
constant which would typically be in ROM.

(I am assuming you meant to specify sizes inside the braces on
"screen".)
--
John W. Temples, III

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

2003\10\27@130932 by piclist

On Mon, 27 Oct 2003, Peter L. Peres wrote:

> #define lcd_puts(s) { while(*s) lcd_putc(*s++); }

That will not work if "s" is a string literal, which is what the OP
was trying to deal with.

--
John W. Temples, III

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

2003\10\27@144623 by Mauricio Jancic

>> (I am assuming you meant to specify sizes inside the braces on
>> "screen".)

Yes, I meant. Anyway I was trying to explain to you your coment:

"If you were able to comment them out, that meant that you weren't
referring to them in your code, so the compiler could have optimized out
the pointer.  Note that in your declaration, "hello world" will be in
ROM, and the pointer str3 will be in RAM."

So, my code refers to the screens in the code, but I can comment it..

BRGS

Mauricio

--
Outgoing mail is certified Virus Free.
Checked by AVG Anti-Virus (http://www.grisoft.com).
Version: 7.0.193 / Virus Database: 260.2.2 - Release Date: 27/10/2003

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

2003\10\27@162327 by Thomas N

Thank you everyone for your help!  This code works for me:
#include <p18f452.h>
void function(const rom char *input)
{
char c;
while (*input)
{
 c = *input++;
}
}
void main (void)
{
function("Hello");
while(1) {}
}
Regards,
Thomas

Mauricio Jancic <RemoveMEjancicspam_OUTKILLspamARNET.COM.AR> wrote:
>> (I am assuming you meant to specify sizes inside the braces on
>> "screen".)

Yes, I meant. Anyway I was trying to explain to you your coment:

"If you were able to comment them out, that meant that you weren't
referring to them in your code, so the compiler could have optimized out
the pointer. Note that in your declaration, "hello world" will be in
ROM, and the pointer str3 will be in RAM."

So, my code refers to the screens in the code, but I can comment it..

BRGS

Mauricio

--
Outgoing mail is certified Virus Free.
Checked by AVG Anti-Virus (http://www.grisoft.com).
Version: 7.0.193 / Virus Database: 260.2.2 - Release Date: 27/10/2003

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

---------------------------------
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears

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

2003\10\29@165803 by Peter L. Peres

2003\10\29@172723 by Wouter van Ooijen

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