468,512 Members | 1,353 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,512 developers. It's quick & easy.

Pointers to specific memory addresses

In coding some embedded software, I frequently find that I need to read
from a specific memory location; it's a hard-wired location that always
contains the same information. A register, for example.

To do so, I tend to define a pointer along the lines of

int* pChipVersionNumber = 0x1000001

for example, where 0x10000001 is the permanent location of the data I'm
interested in.

The compiler I compile embedded code with (in the VDSP environment)
spits out a warning that I've created a pointer in this way, but
generates working code anyway.

Why would the compiler be warning me about this? Are there compilers
that would produce errors, rather than warnings? Is there some other way
I should be explicitly defining a location in memory to read?

To reiterate, these memory locations are not system variables with
nicely defined labels that I can fetch; they're raw locations.

It's common to use predefined values supplied with the chip support
software instead of stating the memory location myself, but in rooting
through the support code I find it usually ends up doing much the same
thing anyway.

'Chops
Jan 12 '08 #1
9 5648
On 2008-01-12 14:24:04 -0500, moschops <mo*****@madasafish.comsaid:
>
int* pChipVersionNumber = 0x1000001

for example, where 0x10000001 is the permanent location of the data I'm
interested in.

The compiler I compile embedded code with (in the VDSP environment)
spits out a warning that I've created a pointer in this way, but
generates working code anyway.

Why would the compiler be warning me about this? Are there compilers
that would produce errors, rather than warnings? Is there some other
way I should be explicitly defining a location in memory to read?
Standard C++ does not support hard-coded addresses. Compilers for
embedded systems usually have a facility for this sort of thing.
Alternatively, you can usually just add a cast:

int *p = (int*)0x1000001;

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Jan 12 '08 #2
Pete Becker wrote:
On 2008-01-12 14:24:04 -0500, moschops <mo*****@madasafish.comsaid:
>>
int* pChipVersionNumber = 0x1000001

for example, where 0x10000001 is the permanent location of the data
I'm interested in.
-
Standard C++ does not support hard-coded addresses. Compilers for
embedded systems usually have a facility for this sort of thing.
Alternatively, you can usually just add a cast:

int *p = (int*)0x1000001;
Better is to make it a const pointer to a volatile object,
so the compiler won't optimize it (got burned by this with
a TI 34020 compiler).

int volatile *const pSOME_REG =
reinterpret_cast<int volatile *>(0x10000001);

And, if it's a read only register :

volatile int *const pSOME_RO_REG =
reinterpret_cast<int volatile const int*>(0x10000001);

volatile const int* const
Jan 12 '08 #3
On 2008-01-12 16:10:28 -0500, red floyd <no*****@here.dudesaid:
Pete Becker wrote:
>On 2008-01-12 14:24:04 -0500, moschops <mo*****@madasafish.comsaid:
>>>
int* pChipVersionNumber = 0x1000001

for example, where 0x10000001 is the permanent location of the data I'm
interested in.
-
Standard C++ does not support hard-coded addresses. Compilers for
embedded systems usually have a facility for this sort of thing.
Alternatively, you can usually just add a cast:

int *p = (int*)0x1000001;

Better is to make it a const pointer to a volatile object,
so the compiler won't optimize it (got burned by this with
a TI 34020 compiler).

int volatile *const pSOME_REG =
reinterpret_cast<int volatile *>(0x10000001);

And, if it's a read only register :

volatile int *const pSOME_RO_REG =
reinterpret_cast<int volatile const int*>(0x10000001);

volatile const int* const
Maybe, maybe not. But it's a separate question from what was asked.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Jan 12 '08 #4
red floyd wrote:
Pete Becker wrote:
>On 2008-01-12 14:24:04 -0500, moschops <mo*****@madasafish.comsaid:
>>>
int* pChipVersionNumber = 0x1000001

for example, where 0x10000001 is the permanent location of the data
I'm interested in.
-
Standard C++ does not support hard-coded addresses. Compilers for
embedded systems usually have a facility for this sort of thing.
Alternatively, you can usually just add a cast:

int *p = (int*)0x1000001;

Better is to make it a const pointer to a volatile object,
so the compiler won't optimize it (got burned by this with
a TI 34020 compiler).
Good thinking, many thanks. I'll probably go easy on the C++ style
reinterpret casting (mainly because the other guy working on this
doesn't speak C++), but it's a good idea.

'Chops
Jan 12 '08 #5
moschops:
In coding some embedded software, I frequently find that I need to
read
from a specific memory location; it's a hard-wired location that
always
contains the same information. A register, for example.

You're using C++ for embedded? Really? Out of curiosity, what
microcontroller are you using that you can get a C++ compiler for? Is
are either of the microcontroller or the compiler expensive?
To do so, I tend to define a pointer along the lines of

int* pChipVersionNumber = 0x1000001

for example, where 0x10000001 is the permanent location of the data
I'm
interested in.

The compiler I compile embedded code with (in the VDSP environment)
spits out a warning that I've created a pointer in this way, but
generates working code anyway.


I don't like when compilers are too liberal. This should be an error.
Why would the compiler be warning me about this?


Be glad that you don't know! If you were to use this compiler for quite
a while, you might some day write code that erroneously uses an integer
for an address (e.g. you write int *p = 9 instead of int *p = 0).

Are there compilers
that would produce errors, rather than warnings?

Yes, all the good ones will give errors for type mismatches.

Is there some other way
I should be explicitly defining a location in memory to read?

As people have said, use a cast:

int *p = (int*)0x6872;
--
Tomás Ó hÉilidhe
Jan 12 '08 #6
Tomás Ó hÉilidhe wrote:
You're using C++ for embedded? Really? Out of curiosity, what
microcontroller are you using that you can get a C++ compiler for? Is
are either of the microcontroller or the compiler expensive?
I'm using this -

http://www.analog.com/processors/vis...testDrive.html

to write code for one of these -

http://www.vmetro.com/category3954.html

I don't like when compilers are too liberal. This should be an error.
Most of the time, I'm in favour of errors over warnings as well. In this
case, though, I'm torn. I create a pointer. The pointer has a value
which is the numerical address of a given unit of the memory. That
numerical address is conceptually an unsigned integer. When I look at
the memory, a pointer holding the address 0x10000001 is identical to an
unsigned integer of the value 0x10000001. The compiler sees a
difference, but the hardware doesn't. I can appreciate that the compiler
should to an extent hold my hand, but on the other hand in embedded work
I need to be close to the hardware.
Be glad that you don't know! If you were to use this compiler for quite
a while, you might some day write code that erroneously uses an integer
for an address (e.g. you write int *p = 9 instead of int *p = 0).
Surely I just _have_ quite deliberately written int* p = 9? Or, in this
case, int* p = 0x10000001 ?

'Chops
Jan 12 '08 #7
On Jan 12, 3:54 pm, moschops <mosc...@madasafish.comwrote:
The pointer has a value
which is the numerical address of a given unit of the memory.
YOU know that, but the compiler doesn't. On some platforms, not all
valid integers are valid pointers. The compiler is enforcing the
standard, which does not make guarantees about hardware.
That
numerical address is conceptually an unsigned integer. When I look at
the memory, a pointer holding the address 0x10000001 is identical to an
unsigned integer of the value 0x10000001.
It might be on YOUR hardware, but it's not on all hardware. The
contents of that memory are a set of bits. The standard can't know
what the implementation does with them.

Imagine for a moment a segmented platform, where pointers are a
segment:offset pair. That 0x10000001 initializer might mean segment
0x1000, offset 0x0001. Or it might mean linear address 0x10000001.
All the compiler is doing is forcing you to declare "I know what I am
doing, and I know this is not portable" by casting.

Imagine a platform that sets the high bit of pointers to indicate that
they are valid.
The compiler sees a
difference, but the hardware doesn't.
What about platforms where unaligned accesses are not allowed?
I can appreciate that the compiler
should to an extent hold my hand, but on the other hand in embedded work
I need to be close to the hardware.
So turn off those warnings or cast them away?
Jan 13 '08 #8
Tomás Ó hÉilidhe wrote:

You're using C++ for embedded? Really? Out of curiosity, what
microcontroller are you using that you can get a C++ compiler for? Is
are either of the microcontroller or the compiler expensive?
Many times a cross-compiler is used. For instance Green Hills for
compiling C++ to run under the VxWorks RTOS. Any number of boards
support that.


Brian
Jan 13 '08 #9
On Jan 13, 12:24 am, moschops <mosc...@madasafish.comwrote:
In coding some embedded software, I frequently find that I need to read
from a specific memory location; it's a hard-wired location that always
contains the same information. A register, for example.

To do so, I tend to define a pointer along the lines of

int* pChipVersionNumber = 0x1000001

for example, where 0x10000001 is the permanent location of the data I'm
interested in.

The compiler I compile embedded code with (in the VDSP environment)
spits out a warning that I've created a pointer in this way, but
generates working code anyway.

Why would the compiler be warning me about this? Are there compilers
that would produce errors, rather than warnings? Is there some other way
I should be explicitly defining a location in memory to read?

To reiterate, these memory locations are not system variables with
nicely defined labels that I can fetch; they're raw locations.

It's common to use predefined values supplied with the chip support
software instead of stating the memory location myself, but in rooting
through the support code I find it usually ends up doing much the same
thing anyway.

'Chops
which cross-compiler are you using?
Jan 13 '08 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by David Casey | last post: by
1 post views Thread by arvind.nm | last post: by
5 posts views Thread by Jeong-Gun Lee | last post: by
2 posts views Thread by Virtual_X | last post: by
8 posts views Thread by Vincent SHAO | last post: by
reply views Thread by NPC403 | last post: by
1 post views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.