While we're on the subject of optimization...

[skimask]

I know there's a way to make this better...
I'm doing characters on a graphic LCD. Everything works well, it's just that the code below is clumsy at best. I know there's a better looking way to do it, I just cannot think of it....
What is it! Anyone? 'cause I'm out of ideas at the moment...(and it'll probably hit me at about 2am while I'm sleeping of course)...

if menu = 1 then
gosub clearalllines
lcdchardata[0] = "R" : lcdpx = 0 : lcdpy = 0 : gosub puttext : lcdchardata[0] = "E" : lcdpx = 1 : lcdpy = 0 : gosub puttext
lcdchardata[0] = "S" : lcdpx = 2 : lcdpy = 0 : gosub puttext : lcdchardata[0] = "E" : lcdpx = 3 : lcdpy = 0 : gosub puttext
lcdchardata[0] = "T" : lcdpx = 4 : lcdpy = 0 : gosub puttext : lcdchardata[0] = " " : lcdpx = 5 : lcdpy = 0 : gosub puttext
lcdchardata[0] = "E" : lcdpx = 6 : lcdpy = 0 : gosub puttext : lcdchardata[0] = "L" : lcdpx = 7 : lcdpy = 0 : gosub puttext
lcdchardata[0] = "M" : lcdpx = 8 : lcdpy = 0 : gosub puttext : lcdchardata[0] = "3" : lcdpx = 9 : lcdpy = 0 : gosub puttext
lcdchardata[0] = "2" : lcdpx = 10 : lcdpy = 0 : gosub puttext : lcdchardata[0] = "7" : lcdpx = 11 : lcdpy = 0 : gosub puttext
lcdchardata[0] = "." : lcdpx = 12 : lcdpy = 0 : gosub puttext : lcdchardata[0] = "." : lcdpx = 13 : lcdpy = 0 : gosub puttext
lcdchardata[0] = "." : lcdpx = 14 : lcdpy = 0 : gosub puttext
gosub clearserialbuffer

[Darrel Taylor]

16F or 18F ?
<br>

[skimask]

16F or 18F ?
<br>

18F4620...
Trying some asm at the moment...but I still know there's something easier and yet more compact than what I've got... just... what... is... it...
Spock...help... me ... here...

[Darrel Taylor]

Here's a slight modification of the old Embedded String thread...

lcdpx VAR byte
lcdpy VAR BYTE
Addr  VAR WORD

ASM
PrintStr macro x, y, Str
    local TheString, OverStr
    goto OverStr
TheString
    data  Str, 0
OverStr
    MOVE?CB  x, _lcdpx
    MOVE?CB  y, _lcdpy
    MOVE?CW  TheString, _Addr
    L?CALL   _StringOut
    endm
ENDASM

Char  VAR lcdchardata[0]
StringOut:
    Readcode Addr, Char           ' Get a character
    if Char = 0 then StringDone   ' Look for Null char, Stop if found
    gosub puttext
    Addr = Addr + 1               ' Point to next character
    lcdpx = lcdpx + 1
    goto StringOut                ' Continue with rest of the string
  StringDone:
return
;-----------------------------------------------------------------------------

Then you can do this...

@  PrintStr  0,0, "RESET ELM327..."
@  PrintStr  0,1, "Hello World!"

HTH,

[skimask]

Here's a slight modification of the old Embedded String thread...

lcdpx VAR byte
lcdpy VAR BYTE
Addr  VAR WORD

ASM
PrintStr macro x, y, Str
    local TheString, OverStr
    goto OverStr
TheString
    data  Str, 0
OverStr
    MOVE?CB  x, _lcdpx
    MOVE?CB  y, _lcdpy
    MOVE?CW  TheString, _Addr
    L?CALL   _StringOut
    endm
ENDASM

Char  VAR lcdchardata[0]
StringOut:
    Readcode Addr, Char           ' Get a character
    if Char = 0 then StringDone   ' Look for Null char, Stop if found
    gosub puttext
    Addr = Addr + 1               ' Point to next character
    lcdpx = lcdpx + 1
    goto StringOut                ' Continue with rest of the string
  StringDone:
return
;-----------------------------------------------------------------------------

Then you can do this...

@  PrintStr  0,0, "RESET ELM327..."
@  PrintStr  0,1, "Hello World!"

HTH,

Actually, I just found what I was looking for a couple of minutes ago...and I think I'll kick myself now... how about a little LOOKUP !
But....I think I like your solution much better...
As soon as I figure out why my '4620 started double-resetting itself and locking up on initial powerup (without changing the code!!! left the room, came back, sat down, did a verify and it started!), I'll give it a whirl and see what happens. I see nothing but good stuff ('cept for that resetting bit. time to throw another chip I think).

[Darrel Taylor]

Storing it as data in program memory uses about 1/4th the code space compared to LOOKUP.

If you'll have a lot of strings to display, it could save a big chunk of space.
Not that you need to worry about it with the 4620. (64kb)
<br>

[skimask]

Got a modification of the PRINTSTR macro for my nokia lcd...

ASM
PrintStr macro x, y, Str
    local TheString, OverStr
    goto OverStr
TheString
    data  Str, 0
OverStr
    MOVE?CB  x, _lcdpx
    MOVE?CB  y, _lcdpy
    MOVE?CW  TheString, _Addr
    L?CALL   _StringOut
    endm
ENDASM
StringOut:
    Readcode Addr, Char : if Char = 0 then StringDone   ' Look for Null char, Stop if found
    gosub puttext : Addr = Addr + 1 : lcdpx = lcdpx + 1 : goto StringOut
StringDone: return

Is there a conditional directive that'll "overload" (I suppose like C++) the PRINTSTR macro to either accept or ignore 2 extra parameters?
In my case, I want to add foreground color and background color, but not neccessarily one or both at the same time...like this

PrintStr macro x, y, Str , forecolor , backcolor

If both are there, great, process them as normal.
If the background color value isn't there, ignore it and don't change it.
If the foreground color value isn't there, ignore both of them and don't change either.
Sure, it's easy enough to make 3 different versions of the same thing, and use 3 different names, i.e. printstr, printstrf (set foreground only ), printstrfb (set both foreground/background), printstrb (set background only).
If I assumed null-zero's would work, that would be fine except that I'm dealing with 8 bits of color (soon to be 16) and a zero-null is a valid color.

[mister_e]

Well, as far as i'm aware of, MPASM don't provide any features like that. If you don't fill all arguments, it will prompt you. That's one downside.

So you'll probably need to build some different version of you macro, one calling the other or variant of.