#ORG controls CONST data but not ROM data ?

nurquhar · Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK

I was looking to place read only data structs into some program memory at a a fixed address.

If I use const in combination with #org I can place my data where I like. However since const puts some extra code in front of the data you can't then use a pointer to the memory address to access it. As the manual says you should use expression an expressions like x = value[9] to access it and not a pointer.

The alternative provided by CCS for address pointer access to program memory data is the 'rom' keyword. This works fine and seems by default to place the data a the top of the PICs memory.

However putting a #org in front of the declaration has no effect on where the compiler places the data in memory.

So for this :

Ttelmah · Joined: 11 Mar 2010 Posts: 19515

Use #ROM......

const, puts the program to retrieve the data in front of the data.
rom, add further code, to allow pointers to be generated to the constant data. This requires it to have a separate table to hold the pointers. By default this second table is in the code where the rom is declared, and the actual data table is put at the top of the available address range.
You can locate both of these at locations in memory, by declaring a function to contain then, and using #ORG to specify where this is to be located. 'label_address' can then be used to find where the actual data table is located. In this case, the pointer table will be near the start of the ORG range, and the data table at the end.

The one that locates a value at a specified location without any control program, is #ROM

So:

nurquhar · Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK

Yes, I can se how these suggestions might work but all gets a bit messey.

Using a function wrapper around the data with a label means the scope of the label is only within the function. Thus label_address would have to be used only in that function. So to get the address you would have to pick it up at run-time by executing the function.

Having had a little try at the wrapper idea I am not sure it works.

Ttelmah · Joined: 11 Mar 2010 Posts: 19515

Note how I'm telling the compiler to place an array of int16 values.
You need to add 'default' to the #org declaration.
Remember rom declarations are are in the rom, so inherently static. Their scope is universal. You just need to copy the label address return value into a global variable.

Best Wishes

nurquhar · Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK

I don't see how putting the 'rom' data declartion inside a function realy helps any. As even if the function is #org'ed to a fixed memory address the compiler puts the function at the #org address ok but it still puts the data where it likes at the top of memory.

Using #ROM with a list of words will work as you suggest but makes the code much less readable as compared to the struct assignement syntax.

It just seems odd that 'const' can be controlled with #org and 'rom' can't. Seems like a usefull feature to me if CCS are listening.

nurquhar · Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK

Well it could be I mis-understood something. I just went back to trying 'const' again and I don't see any code before the program data for the structure access.

That is :

Ttelmah · Joined: 11 Mar 2010 Posts: 19515

Lets start with. Second line of your first post:

"However since const puts some extra code in front of the data you can't then use a pointer to the memory address to access it".

Key here is that what extra code you get, depends on the processor involved.

The processor is always generating extra code (rom, or const), but will put it in different locations, depending on processor, and what access you actually do.

Now rom is special. With rom, the compiler generates a 'pointer table', which is stored instead of the actual data in the code, and then the data itself is then stored at the top of the available data range. If you use 'default' with a ORG statement, this sets the available data range. The pointer table, can then be used to generate pointer accesses to the data. This then allows a rom data construct to be put at a known location.

However I have to ask if you really 'need' pointer access?. You can always use address access. Here if a table is at a known location, the read_program_memory function will allow you to access it. Not quite as simple as just using *, but with a couple of macros, this can be made almost as easy.

It is vital to understand, that you can't do 'traditional' pointer access to data in the ROM. This has been described dozens (hundreds) of times before, and is down to the fact that the ROM is not part of the same data space as the RAM on a PIC. So you can't take an address like 0x100, and say fred=*(0x100), and access the ROM. This will access address 100, but in the RAM instead. There is no single instruction fetching of ROM data, instead, you have to setup a table read, to access the ROM area. This is a fundamental difference about the PIC. Now CCS allows this to be hidden, using the rom data construct, automatically generating flags to mark the addresses as 'ROM', but even with this done, you can't then access the table using simple pointers, the compiler at all times has to 'know' that you are using pointers to ROM.

Best Wishes