|
|
View previous topic :: View next topic |
Author |
Message |
guest Guest
|
large tables, small ram, no ROM pointers... |
Posted: Fri Apr 23, 2004 1:47 am |
|
|
I'm porting some code that relies on pointers to data held in ROM. The flavour of the code is:
Code: |
const char * data_ptr;
const char the_data1 = {0, 0, ...};
const char the_data2 = {1, 2, ...};
some_func(i) {
switch(i) {
case A : data_ptr = the_data1; break;
default: data_ptr = the_data2; break;
}
do_action(data_ptr);
}
|
The tables are biggish, and the code is going to be difficult to change to using indexed access by name.
Any suggestions? Am I missing something here? |
|
|
Ttelmah Guest
|
Re: large tables, small ram, no ROM pointers... |
Posted: Fri Apr 23, 2004 2:02 am |
|
|
guest wrote: | I'm porting some code that relies on pointers to data held in ROM. The flavour of the code is:
Code: |
const char * data_ptr;
const char the_data1 = {0, 0, ...};
const char the_data2 = {1, 2, ...};
some_func(i) {
switch(i) {
case A : data_ptr = the_data1; break;
default: data_ptr = the_data2; break;
}
do_action(data_ptr);
}
|
The tables are biggish, and the code is going to be difficult to change to using indexed access by name.
Any suggestions? Am I missing something here? |
Use numbers.
You cannot have 'pointer' to ROM, but if the_data1, is an array, you can simply code 'data_ptr', as an integer, that is the address in the array.
You can join your arrays together (provided they fit inside a ROM page), and just hand the 'start point' in the larger array to the function.
Best Wishes |
|
|
Ttelmah Guest
|
Re: large tables, small ram, no ROM pointers... |
Posted: Fri Apr 23, 2004 2:07 am |
|
|
The tables are biggish, and the code is going to be difficult to change to using indexed access by name.
Any suggestions? Am I missing something here?[/quote]
Use numbers.
You cannot have 'pointer' to ROM, but if the_data1, is an array, you can simply code 'data_ptr', as an integer, that is the address in the array.
You can join your arrays together (provided they fit inside a ROM page), and just hand the 'start point' in the larger array to the function.
Best Wishes[/quote]
Add to this, that you can use a 16bit 'number', and use the top byte, as an 'index' to which array to use. So if the value is 0x00xx then the subroutine can use 'data1', while if it is 0x01xx, it can select 'data2' etc..
Remember also, that you don't have to structure your array usin the const declarations (which add a significant overhead with the 'fetch' header attached to each array). Instead use a #ROM declaration to store the array. and the read_program_eeprom call to fetch the data from an address.
Best Wishes |
|
|
guest Guest
|
thanks... |
Posted: Fri Apr 23, 2004 9:17 pm |
|
|
Thanks, useful suggestions. I'll try the #ROM (or #ORG??) approach first. |
|
|
guest Guest
|
read_program_memory() on 16C745? |
Posted: Sat Apr 24, 2004 1:41 am |
|
|
I'm getting the message:
*** Error 12 "C:\9.c" Line 268(1,20): Undefined identifier read_program_memory
How do I access ROM based tables again? Micro is PIC16C745...
I've tried read_program_eeprom() also with same result. |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1937 Location: Norman, OK
|
Read_Program_Memory Problem |
Posted: Sat Apr 24, 2004 7:35 am |
|
|
What version are you using?
If you are using 3.190 this is a bug that cropped up. 3.189 seems to work fine though... |
|
|
Ttelmah Guest
|
Re: read_program_memory() on 16C745? |
Posted: Sat Apr 24, 2004 7:55 am |
|
|
guest wrote: | I'm getting the message:
*** Error 12 "C:\9.c" Line 268(1,20): Undefined identifier read_program_memory
How do I access ROM based tables again? Micro is PIC16C745...
I've tried read_program_eeprom() also with same result. |
Change the chip...
Unfortunately, the ability to use the 'read_program_memory' function, requires that the _chip_ supports this capability. Generally, only 'F' designated chips have this ability (it is part of the support to read/write the flash memory). In chips without this ability, the only way to store 'numbers' into the ROM, is to code each byte, using a RETLW function, and then use a table based jump to the code. This implicitly limits the maximum table size, requiring it to fit in a page of ROM (including the access code), and wastes a significant amount of space.
Why these modern 'USB' chips are not 'F' designs, is odd...
Best Wishes |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|