16f687 - Where is the data stored?

[rmteo]

Storing spaces is extremely inefficient. Create a routine that pads the message with the appropriate number of leading/trailing spaces before sending it out to the LCD.

[andywpg]

Storing spaces is extremely inefficient. Create a routine that pads the message with the appropriate number of leading/trailing spaces before sending it out to the LCD.

I suppose I could store each message without spaces, then write a unique "stop character".

Then I could just count the characters to the stop character, then calculate the number of spaces needed to pad it to the center of a 16 character line.

The only thing is accessing the right message. I intended to send the message number as part of the data block. I was going to calculate the start address of the message from the message number, and retrieve 16 characters. I guess I could just send the start address as the message number, then retrieve characters until I encounter the stop character. That would work, and is WAY more efficient (in both memory space and processor cycles).

Thanks!

[HenrikOlsson]

Why not clear the screen, move the cursor to the first position, print the message?

CursorPos VAR BYTE          ' 0=first line first char, 64=second line first char (I think, usally...)

CursorPos = 1
GOSUB Clear_and_set_cursor
LCDOUT "Report to pit"

Pause 2000

CursorPos = 5
GOSUB Clear_and_set_cursor
LCDOUT "STOP"

' and so on

END

Clear_and_set_cursor:
   LCDOUT $FE, 1, $FE, ($80 + cursorposition)
   RETURN

/Henrik.

[andywpg]

Why not clear the screen, move the cursor to the first position, print the message?
/Henrik.

Exactly what I plan on doing. Since each line is usually somewhat less than 16 characters, though, I want to have some leading spaces to bring each line to the center of the display. I'll just calculate how many characters less than 16 a line is, then divide that by two and use that as my pad in the front.

I just figure having it centered makes it easier for the driver to read when he's going fast a trying to avoid someone else.

[Charlie]

Storing spaces is extremely inefficient. Create a routine that pads the message with the appropriate number of leading/trailing spaces before sending it out to the LCD.

Of course, shipping product with unused memory is pretty inefficient too. If there's plenty of unused program store, why waste time improving efficiency, particularly for a code block that isn't very reusable?
To paraphrase old movies, "smoke 'em if you've got 'em, lads." But if things are tight, I agree completely.