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

Closed Thread
Results 1 to 32 of 32

Hybrid View

  1. - 4th January 2007, 07:21 #1
    Darrel Taylor's Avatar
    Darrel Taylor
    Darrel Taylor is offline Fanatical Contributor
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Did you find this post helpful? Yes | No

    Default

    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>
    DT
  2. - 7th January 2007, 08:51 #2
    skimask's Avatar
    skimask Guest

    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Darrel Taylor View Post
    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.
  3. - 7th January 2007, 08:58 #3
    mister_e's Avatar
    mister_e
    mister_e is offline Contributor
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898

    Did you find this post helpful? Yes | No

    Default

    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.
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.
  4. - 7th January 2007, 09:10 #4
    skimask's Avatar
    skimask Guest

    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by mister_e View Post
    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?
  5. - 7th January 2007, 09:48 #5
    Darrel Taylor's Avatar
    Darrel Taylor
    Darrel Taylor is offline Fanatical Contributor
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Did you find this post helpful? Yes | No

    Default

    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>
    DT
  6. - 7th January 2007, 09:57 #6
    skimask's Avatar
    skimask Guest

    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Darrel Taylor View Post
    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.
  7. - 7th January 2007, 18:05 #7
    Darrel Taylor's Avatar
    Darrel Taylor
    Darrel Taylor is offline Fanatical Contributor
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Darrel Taylor View Post
    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>
    Quote Originally Posted by skimask
    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>
    DT
  8. - 8th January 2007, 03:04 #8
    skimask's Avatar
    skimask Guest

    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Darrel Taylor View Post
    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>
    That sounds about right, and makes quite a bit more sense.
    So noted for the next project....
  9. - 7th January 2007, 10:37 #9
    skimask's Avatar
    skimask Guest

    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Darrel Taylor View Post
    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...
  10. - 7th January 2007, 11:05 #10
    Darrel Taylor's Avatar
    Darrel Taylor
    Darrel Taylor is offline Fanatical Contributor
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Did you find this post helpful? Yes | No

    Default

    Sweet!

    Let me know how it is after optimizing the rest. Just for curiosity sake.
    <br>
    DT
  11. - 7th January 2007, 11:35 #11
    skimask's Avatar
    skimask Guest

    Did you find this post helpful? Yes | No

    Default

    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...
  12. - 7th January 2007, 12:55 #12
    BigWumpus's Avatar
    BigWumpus
    BigWumpus is offline Member
    Join Date
    Oct 2004
    Location
    Hangover, Germany
    Posts
    289

    Did you find this post helpful? Yes | No

    Wink

    Try to replace the "goto" inside the macro by a "bra".
    PBP 2.50C, MCS+ 3.0.0.5, MPLAB 8, MPASM 5.14, ASIX Presto, PoScope, mE mikroBasic V7.2, PICKIT2
  13. - 7th January 2007, 18:14 #13
    Darrel Taylor's Avatar
    Darrel Taylor
    Darrel Taylor is offline Fanatical Contributor
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959

    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by BigWumpus View Post
    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>
    DT
  14. - 8th January 2007, 03:07 #14
    skimask's Avatar
    skimask Guest

    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Darrel Taylor View Post
    Sure, good idea. It'll save another word for each instance of PrintStr.
    And it only takes one edit.
    <br>
    And another 129 words saved, brings me up to 9,917 saved so far.
    At this rate, I'll be able to fit the program into a 10F202 soon !
« Previous Thread | Next Thread »

Similar Threads

  1. Stable Adc Reading Routine
    By gebillpap in forum General
    Replies: 27
    Last Post: - 13th May 2015, 02:18
  2. code size VS speed optimization setting?
    By Kamikaze47 in forum mel PIC BASIC Pro
    Replies: 7
    Last Post: - 28th April 2008, 14:38
  3. Multiple if then optimization
    By Mugelpower in forum mel PIC BASIC Pro
    Replies: 35
    Last Post: - 5th March 2008, 12:15
  4. Power drain, coin cell, while we're on the subject
    By skimask in forum Off Topic
    Replies: 2
    Last Post: - 1st May 2006, 13:45

Members who have read this thread : 0

You do not have permission to view the list of names.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Forum Rules