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

[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]

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>

I just converted a few of my strings over to your format....
And after fighting with it for about an hour, I figured out that the thing is case sensitive...jeeze...what next...
I'm up to 40K used out of 64K on the '4620, might have to go to a 4685 (or maybe even an '8722 with my little 40 pin adapter I built awhile back). Hopefully this little routine helps me save a LOAD of space. I'm not even halfway done with my program yet.

[mister_e]

Well, using an external EEPROM have it's advantages as well. If you Strings are LCD dedicated, you can also format them the right way in a HEX Editor.

I use bpsoft Hex WorkShop.

[skimask]

Well, using an external EEPROM have it's advantages as well. If you Strings are LCD dedicated, you can also format them the right way in a HEX Editor.

I use bpsoft Hex WorkShop.

I'm using a graphic LCD with a whole set of subroutines to display the characters. I suppose I could probably stored the lines in the eeprom as hard coded characters (1 byte per line, 6 lines per character) and pull them out serially (actually 5x7 character font, could probably do some compression on those to save the extra byte here and there).
When I run out of room on the '4620, I'll plug an eeprom in and see what happens...or just go with a '4685 (or '8722).
Nothing like extra space to cover for sloppy programming!

uh-hum...Windows Hate it, but what do we all use?

[Darrel Taylor]

Just keep in mind that no matter how much Flash the PIC has, PBP can only use the first 64kb of it. Same as your 4620.

The additional space can be used to store data, but not PBP program code.
<br>

[skimask]

Just keep in mind that no matter how much Flash the PIC has, PBP can only use the first 64kb of it. Same as your 4620.

The additional space can be used to store data, but not PBP program code.
<br>

Really? I made a program awhile back for my '8722 (with my adapter, plugged into a slot originally for a '4620). I copied/pasted a load of code (a load of LCDOUT statements) back to back just to fill it all up (I wanted to see what would happen)...and it programmed...the full 128K and it ran, all the way to the end.
It looked something like this:
LCDOUT "START"
LCDOUT "SAME" a whole bunch of these lines
LCDOUT "END" : STOP a line like this at the end, verified in the .lst file as being at the end of programmable space

I could've been wrong, but the programmer software (Warp13a) showed it being full up. And the same code wouldn't fit into a '4620. And if you think about it, the '8722 only has 64K-words, the '4620 32K-words, so maybe PBP can still take it.

[Darrel Taylor]

Just keep in mind that no matter how much Flash the PIC has, PBP can only use the first 64kb of it. Same as your 4620.

The additional space can be used to store data, but not PBP program code.
<br>

Really?

No, not really. That didn't come out right at all.

The space above 64K can't be accessed by the READCODE statement. So your string data has to be in the first 64K. The space above 64k can store data, but READCODE can't use it. It's possible to write an ASM routine that does the same thing as readcode and uses the upper space, but it's not built in to PBP.

Hope that clarifies it a bit.
<br>

[skimask]

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>

Kudos to you and all that. I just went thru and converted all of my major string routines to your embedded routine example.
So far, I've saved 7,486 in code space (started with $9C22, now I'm only using $7EE4 of space).
And I've still got to optimize the rest of the code...

[Darrel Taylor]

Sweet!

Let me know how it is after optimizing the rest. Just for curiosity sake.
<br>

[skimask]

Down from $9CC4 to $7688, saved 9,788 so far, and I think I'm about done, getting to that point of diminishing returns. That and it's 5:30am....I'm just about spent...

[BigWumpus]

Try to replace the "goto" inside the macro by a "bra".

[Darrel Taylor]

Try to replace the "goto" inside the macro by a "bra".

Sure, good idea. It'll save another word for each instance of PrintStr.
And it only takes one edit.
<br>