#device CONST=ROM problem

[zdedeoglu]

Hello,
I am trying different things about 1 week. I don’t understand anything. Please help me.

We use this directive.
#device CONST=ROM
We have got too big lookup table. Table is approximately 3kB long. We write this table like this:
char const Menu[] =
{
"ABCDEFGHIJKLM |"
}
And we take this tables address like this:
LcdKarakterAdresi = &Menu[0];
This code is written on 18F452 and this code %66 full the program memory and this code is running properly.
(Another interesting thing, when we open the hex file one elnec programmer software, the lookup table exist. But when we are open the cof file on the MPLAB or ISIS for simulation, the lookup table is not exist. ???)

We write some codes and the program memory %71 full. But the program is not running.
After then we delete the #device CONST=ROM directive.
We change the code for taking the tables address like this.
LcdKarakterAdresi = &Menu;
And then the code is increased to %97. But the code is running now.


I don’t understand anything. Please explain #device CONST=ROM directive.
Help me, thank you.
Zafer

[Ttelmah]

The manual states, that when you use const, you cannot use "ptr = &table[i]". In fact this is not true, if you are passing constants in RAM (the default behaviour in ANSI mode), but explains why your first code works. This though is why your second version is larger, but works.
Use the _ROM_ declaration, instead of the const declaration. This allows pointers to be used, and still stores the data in ROM. Just use the ROM keyword, instead of the 'const' keyword. The manual is 'awful' about the handling of ROM, and const, with the different device declaration. Unfortunately, it is an area that has 'grown', and unless you know the different functions, and how they work, can appear as a 'black art'.
Remove the #nolist directive at the start of the device declaration file, to see the tables in the simulator.

Best Wishes

[ivan]

if you use #rom
like
#rom 0x2100={1,2,3,4,5,6,7,8}
after you can use READ_PROGRAM_MEMORY (address, dataptr, count );
or also
read_program_eeprom (address);
Tred to send a long 512 table over i2c and did work perfect

[picerno]

in my test with a pic18f2620, why this code work

[picerno]

sorry!! the compiler version is 4.068

[Ttelmah]

In what way "doesn't it work"?.
Have just compiled both, using 4.068, and with a breakpoint at the start of the delay, both have the sequence 'fghil\0', in the 'data' variable when run.
Exactly what they should have.

Best Wishes

[Guest]

I use MPLAB and ICD2. In MPLAB SIM it works and in data I find "fghil" but when I program the PIC, I don't find the exact data.
I have got the same proble when I use a 1D ROM array greater than 15 element.
It's strange!

[ivan]

why are you using "char ROM"
is same as "char const"?

[Ttelmah]

Char const, does _not_ allow pointers.
Char rom, does.

There is (supposedly) a compiler switch, to change the default operation to match the Char rom form, but this has never worked quite right for me. The Char rom form does.

I have arrays of over 1000 elements, running without problems using this form, so cannot understand 'why' yours fails at 15 elements, unless something is going wrong in the indexing. There is a _large_ caveat with this form, in that the optimiser will sometimes interfere with elements that it doesn't think are being used. Might be a problem here (try the lowest optimiser setting, and see what happens). When you program it into the PIC, you must be doing something differently (adding serial output for example, to see what is happening), so I'd be very careful to make sure that something in this is not affecting the data...

Best Wishes

[ivan]

if "ROM" put data in rom is same as const but if "*ptr" are in rom how can
the &address work? this should change value of ptr to location of address ram but I can't find ROM command in manual (only #rom preprocessor)
I can't get explain

[Ttelmah]

The 'key' perhaps, is to understand the history.
Originally, none of the PIC's had code to allow the ROM to be directly accessed. The 'const' form, dates from this time, and worked, by actually generating a program that returned the addressed value, using the RETLW instruction, and a jump into a table of these instructions. Though the chips, in many cases, now have instructions to access the ROM, the const form is still basically done the same way. When you generate 'char const data', a program is inserted (now one using the flash program memory access instructions), _followed_ by the data. The logical 'name', accesses the start of this program, rather than the data table in the ROM. Hence pointer constructions are awkward.
The ROM form (and supposedly the const form, if you use the #device const=ROM directive - however this still seems to give problems - see below..), instead behaves more along the lines of the #ROM directive, storing a table of the basic data in the ROM, and using the normal read_program memory access code to access this, but without you having to get involved in finding the data. Now, with this form, provided the code knows you are talking to the ROM, rather than the RAM, given the start address of the table, and the size of the elements, it can address any element you want, hence address operations become easy to program (and are supported). Downside, is that slightly more work is involved for normal accesses (without using pointers). For this, the 'old' form, allowed you to simply call the function, with the required index, and just returned the value, while the 'newer' form, requires such an access to effectively 'go through' the pointer based access.
Now the #device const=ROM directive, _works_, provided you don't use the CCS 'shortcut', of accessing a constant string, using a function that expects a single int8 value, which is then repeatedly called with the successive values from the access program. Unfortunately, some of the internal CCS funtions use this shortcut, and it is this that then fails if this option is enabled. Hence, for my money, it is better, to leave the default behaviour in place, and only use the latter access format, where you actually want to use pointers, by using the rom keyword, instead of the const keyword. Currently, 'fully' switching mode, gives problems (which is what I think was originally happening to the originating poster).
The rom form is documented in the 'readme.txt', that comes with the compiler. This is commonly done for 'new' features, for a number of versions, till the manual is updated, and should always be used as if it is an 'extra' page in the manual.

As a comment, you don't have to declare the pointer using the 'rom' type. So the declaration only needs to be:

char ROM test[2][10] = {"abcde","fghil"};
char *ptr;

This is rather 'neat', and allows ROM strings stored this way, to be interchangeably used in code that expects data in RAM.

Best Wishes

[ivan]

ok all clear const now is ROM before was ROMI (readme.txt)

#device CONST=READ_ONLY //ansi mode store in ram as read only
#device CONST=ROM //store in rom for optimized access by pointer(new mode or using "rom" instead of "const")
#device CONST=ROMI //store in rom optimized for access from indexed arrays(ccs default when using "const")

old ROM now is ROMI and now ROM is new method need be delcared with #device or using rom instead of const

the problem was not need use ROM for *ptr I think

this correct?
thanks all

[picerno]

I have tried to reduce optimisation but nothing change.
If I declare a pointer without ROM type, it doesn't work.
I notice another thing: in watch window I don't see test variable and I see "restricted memory". Is it normal?

[picerno]

Today I have tried with a PIC16F913 also but it doesn't work

[picerno]

same problem with 18F6527: who help me? with ROM type I cannot even find data in opcode hex: where are they?