Printing string constants (and local variables)

[nick ray]

In my application I have a number of different strings stored as constants in ROM, which I need to display on an LCD for status displays, menus etc.

What is the best way to do this? I have a simple bit of code to write the string to the LCD, which I would normally put into a procedure, except that I can't do this because I can't pass a pointer to the ROM string constants.

So as far as I see it it means either repeating code inline or a seperate call for each string.. e.g. menu1() menu2() etc. Unless I'm missing something?

Which brings me to the local variables question: my simple code uses a for statement and a char counter, which would be a local variable if in a procedure. Does the compiler allocate a seperate byte of RAM for each local variable in each procedure, or re-use a scratch RAM location?

Thanks,
Nick
___________________________
This message was ported from CCS's old forum
Original Post ID: 1101

[Tomi]

<font face="Courier New" size=-1>Thanks for CCS and V3 compiler you have a not too easy but good way to display menus from ROM nearly as using pointers.
The concept I use is based on the possibility to use mixed character and hexadecimal codes of the new V3 compiler.
Here is my code.
The menu strings are implemented as NULL-separated substrings so you have only one reference for all of strings.
There is another array to hold the start indexes of the substrings and the hardest work is to fill out this array (count the characters, the NULL separator (\x00) is ONE character.
Be careful with the constant string, don't use TABs for a better readability.

About local variables: yes, CCS C re-uses RAM locations. This is one of the greatest hits of CCS C.

And now the code:

#include <16F877.h>
#fuses XT,NOWDT,PUT,NOPROTECT,NOBROWNOUT,NOLVP
#id 1,0,0,0
#use delay (clock=4000000,restart_wdt)
#include "lcd.c"

/* NULL separated substrings as Visual C++ does */
const char gMenus[58] = {"First menu\x00Second menu\x00
Third menu\x00Forth menu\x00What to do\x00"};
/* the offset table for the substrings */
const char gOffset[5] = {0,11,23,34,45};

/* to display a substring (menu) from 0-4 in my example */
void DisplayMenu(char menuID)
{
char offset,toSend;
if (menuID > 4) return; // there are only 5 menus in my example
offset = gOffset[menuID]; // load the start index from table
while (toSend = gMenus[offset]) { // be careful: it is NOT "==" !!!
offset++;
lcd_putc(toSend);
}
}

/* be careful with the body of the "while()". It is NOT a compare instruction.
It means: "load var. toSend from gMenus. Evaluate the transfer. If it is not NULL
(so the toSend var. is not NULL after the move) repeat */

Usage:
char a = 2;
DisplayMenu(0);
DisplayMenu(a);</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 1102

[Nick Ray]

OK, thanks, I see what you mean.

FYI, this is my code snippet for writing the string:

char n=0;
while (msg[n])
lcd_putc(msg[n++]);

Saves the need for the intermediate SendTo variable. Obviously in your implementation n becomes the offset.

Regards,
Nick


:=<font face="Courier New" size=-1>Thanks for CCS and V3 compiler you have a not too easy but good way to display menus from ROM nearly as using pointers.
:=The concept I use is based on the possibility to use mixed character and hexadecimal codes of the new V3 compiler.
:=Here is my code.
:=The menu strings are implemented as NULL-separated substrings so you have only one reference for all of strings.
:=There is another array to hold the start indexes of the substrings and the hardest work is to fill out this array (count the characters, the NULL separator (\x00) is ONE character.
:=Be careful with the constant string, don't use TABs for a better readability.
:=
:=About local variables: yes, CCS C re-uses RAM locations. This is one of the greatest hits of CCS C.
:=
:=And now the code:
:=
:=#include <16F877.h>
:=#fuses XT,NOWDT,PUT,NOPROTECT,NOBROWNOUT,NOLVP
:=#id 1,0,0,0
:=#use delay (clock=4000000,restart_wdt)
:=#include "lcd.c"
:=
:=/* NULL separated substrings as Visual C++ does */
:=const char gMenus[58] = {"First menu\x00Second menu\x00
:=Third menu\x00Forth menu\x00What to do\x00"};
:=/* the offset table for the substrings */
:=const char gOffset[5] = {0,11,23,34,45};
:=
:=/* to display a substring (menu) from 0-4 in my example */
:=void DisplayMenu(char menuID)
:={
:=char offset,toSend;
:=if (menuID > 4) return; // there are only 5 menus in my example
:=offset = gOffset[menuID]; // load the start index from table
:=while (toSend = gMenus[offset]) { // be careful: it is NOT "==" !!!
:=offset++;
:=lcd_putc(toSend);
:=}
:=}
:=
:=/* be careful with the body of the "while()". It is NOT a compare instruction.
:=It means: "load var. toSend from gMenus. Evaluate the transfer. If it is not NULL
:=(so the toSend var. is not NULL after the move) repeat */
:=
:=Usage:
:=char a = 2;
:=DisplayMenu(0);
:=DisplayMenu(a);</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 1103

[Tomi]

:=Saves the need for the intermediate SendTo variable. Obviously in your implementation n becomes the offset.

Oh, no Sir.
Your code is longer (the difference is only one word, that's true) and eats more RAM because of the DOUBLE access of the string array, here is the list part:
/* This is mine */
CCS PCW C Compiler, Version 3.040, 6859

Filename: D:\PICfejl\Cben\multistr.LST

ROM used: 268 (3\%)
Largest free fragment is 2048
RAM used: 6 (2\%) at main() level
19 (5\%) worst case
Stack: 3 locations

.................... while (toSend = gMenus[offset]) {
00BB: MOVF 23,W
00BC: CALL 004 // the only access
00BD: MOVWF 78
00BE: MOVWF 24 // store
00BF: MOVF 24,F // for compare
00C0: BTFSC 03,2
00C1: GOTO 0FE
.................... offset++;
00C2: INCF 23,F
.................... lcd_putc(toSend);
00C3: MOVF 24,W
00C4: MOVWF 25

/* And this is yours */

ROM used: 269 (3\%)
Largest free fragment is 2048
RAM used: 6 (2\%) at main() level
21 (6\%) worst case
Stack: 3 locations

.................... while (gMenus[offset])
00BB: MOVF 23,W
00BC: CALL 004 // first access
00BD: MOVWF 78 // save the result
00BE: MOVF 78,F
00BF: BTFSC 03,2
00C0: GOTO 0FF
.................... lcd_putc(gMenus[offset++]);
00C1: MOVF 23,W // 2nd access starts
00C2: INCF 23,F
00C3: CALL 004 // 2nd access
00C4: MOVWF 26 // and the second save
00C5: MOVWF 27
___________________________
This message was ported from CCS's old forum
Original Post ID: 1104

[nick ray]

Fair enough - I didn't realise that the string access used RAM like it does. I'm sure there are plenty of other caveats I'm going to learn about this compiler as time goes on...

Regards,
Nick


:=:=Saves the need for the intermediate SendTo variable. Obviously in your implementation n becomes the offset.
:=
:=Oh, no Sir.
:=Your code is longer (the difference is only one word, that's true) and eats more RAM because of the DOUBLE access of the string array, here is the list part:
:=/* This is mine */
:=CCS PCW C Compiler, Version 3.040, 6859
:=
:= Filename: D:\PICfejl\Cben\multistr.LST
:=
:= ROM used: 268 (3\%)
:= Largest free fragment is 2048
:= RAM used: 6 (2\%) at main() level
:= 19 (5\%) worst case
:= Stack: 3 locations
:=
:=.................... while (toSend = gMenus[offset]) {
:=00BB: MOVF 23,W
:=00BC: CALL 004 // the only access
:=00BD: MOVWF 78
:=00BE: MOVWF 24 // store
:=00BF: MOVF 24,F // for compare
:=00C0: BTFSC 03,2
:=00C1: GOTO 0FE
:=.................... offset++;
:=00C2: INCF 23,F
:=.................... lcd_putc(toSend);
:=00C3: MOVF 24,W
:=00C4: MOVWF 25
:=
:=/* And this is yours */
:=
:= ROM used: 269 (3\%)
:= Largest free fragment is 2048
:= RAM used: 6 (2\%) at main() level
:= 21 (6\%) worst case
:= Stack: 3 locations
:=
:=.................... while (gMenus[offset])
:=00BB: MOVF 23,W
:=00BC: CALL 004 // first access
:=00BD: MOVWF 78 // save the result
:=00BE: MOVF 78,F
:=00BF: BTFSC 03,2
:=00C0: GOTO 0FF
:=.................... lcd_putc(gMenus[offset++]);
:=00C1: MOVF 23,W // 2nd access starts
:=00C2: INCF 23,F
:=00C3: CALL 004 // 2nd access
:=00C4: MOVWF 26 // and the second save
:=00C5: MOVWF 27
___________________________
This message was ported from CCS's old forum
Original Post ID: 1142