Extending the Program Memory

Hi Guys ,

I was looking for links on how to expand the program memory of 18F PIC , while still using PBP3 as the compiler
i suspect ill have to also sub divide the code so that it would be able to work ???
can someone advise

cheers


sheldon

i suspect this is an adaption of a bootloader requirement , but given i still want to use a majority of the pic program memory , wondering how i would do it to make the program jump to correct external address when needing that code ,

when compliling would i need 2 hex files , 1 for the main chip and the other for a sudo chip that can be complied ???

I am sure someone has had this issue , hows it best solved ?

regards

Sheldon

some pic18's have 128k flash if that's not enough get an arduino mega 2560 clone , less than $20 256k flash 8k ram 4k eprom you'll never look back I love them

yes i been looking at those chips and board , am far down the rd with the chip i am on and just thinking i could add a bit of extra flash if need be , the chip have is 128k , and the code uses 50% of that now and have a ways to go

if i wanted to put menus and lookup tables , which have some code as subroutines as a separate structure for storage , how would this be done so that i can call from main program

???

I'm afraid (to the best of my knowledge) you will not be able to run code from external memory or from RAM. Your best bet is to place all the memory heavy arrays/tables into external EEPROM and use the PICs ROM space for code alone. Even so, the extra time needed to store/retrieve entries from the EEPROM will slow down your processes.

THANKS JERSON ,

i could put some of the data into the available sd as hex data tables , but i am sure it will be a speed issue

i am surprised that data strings for menus are chewing up so much space so quickly
i still have about 60k left in the pic but i only just getting started on the menu system

cheers

Sheldon

Hi,

Quote:

---

i am surprised that data strings for menus are chewing up so much space so quickly

---

Yeah, that is one of my big "concerns" as well. I have a couple of projects which could benefit from a more "verbose" user interface but each and every byte in a HSEROUT, ARRAYWRITE, LCDOUT etc statement increases the footprint of the generated code by 6 bytes so it eats away available space quickly. The nice thing with these commands is that it's SO easy to mix static strings with variables, formating and so on.

For static data there are other ways of doing it of course, there's the "strings in codespace" thread from a couple of years ago and someday I need to figure out how to use that.

/Henrik.

well as space gets tigher i may need to look at the structure closer , when i hit 100k ill be worried