storing data in code memory of 87LPC764

To Mark Odell

"I ask why? Why do you need a variable at a particular address? "

Have you not heard of memory-mapped I/O, I rarely use nothing but.

Erik

To Mark Odell

"I ask why? Why do you need a variable at a particular address? "

Have you not heard of memory-mapped I/O, I rarely use nothing but.

Erik

I have heard of memory mapped I/O and I use _at_ for just that. However, I never want the C run-time to write initial values to it! Do you? If the lcdControlReg is located at 0x8000 what does it mean to give it an initial value of 5? Why would it be better to have the C run-time do this for you than simply doing it explicitly?

- Mark

I now see that you mis-understood me. I didn't ask why one would want a memory mapped address at a particular address. I asked why you'd want a *variable* at a particular address. A variable here means plain old program data, *not* memory mapped hardware object. Didn't you read the rest of the post?

- Mark

Mark wrote:
"I asked why you'd want a *variable* at a particular address."

As I said, judging by the number of times the question gets asked here, there's a lot of people who do want to do it!
They don't usually say why they want to do it, so it's hard to say whether they have good reasons!

I agree that it's probably not wise to rely on the 'C' runtime to initialise your memory-mapped peripherals, but I can think of 2 applications where an _at_ with an initialiser seems reasonable:

1. Cases such as the original post here, where some configuration values need to be set in a specific location - especially if it's in ROM;

2. To place some sort of "signature" (eg, version info) into a known location in ROM.

1. Cases such as the original post here, where some configuration values need to be set in a specific location - especially if it's in ROM;

I think that this is best handled in the startup code along with the reset of the chip initialization.

Jon

Andrew wrote:
As I said, judging by the number of times the question gets asked here, there's a lot of people who do want to do it! They don't usually say why they want to do it, so it's hard to say whether they have good reasons!

True, so let's show them alternatives that they can have now.

For case 1: For the ROM case linker will create an image size large enough to capture the _at_ address. On a 64kB ROM this may not pose a real problem, but in principle I don't like padding out my image (.bin) just to get up to the checksum value up at 0xFFFE. What if I have to download this upgrade image over a slow link?

For the RAM case, be explicit and just do it at run-time. I, again, stipulate that no one in their right mind would allow some memcpy routine to initialize memory mapped I/O addresses in XDATA.

As for case 2: We really need to get comfortable with .a51 files.

:-)

- Mark