Trying to read hardware memory from pointer?

[Brad]

Hi,

Am trying to read one byte at location 0xFFF0 000E in an embedded system.

I cast a pointer to int, then try to stuff the above address in, then
reference whats at the location? wont compile, tried many different
variations of this; any ideas appreciated.

[Ian Collins]

Brad wrote:

Hi,

Am trying to read one byte at location 0xFFF0 000E in an embedded system.

I cast a pointer to int, then try to stuff the above address in, then
reference whats at the location? wont compile, tried many different
variations of this; any ideas appreciated.

Show us what you have tried, what do you mean by "cast a pointer to int"?
--
Ian Collins.

[John Devereux]

"Brad" <ro*********@ve rizon.net> writes:

Hi,

Am trying to read one byte at location 0xFFF0 000E in an embedded system.

I cast a pointer to int, then try to stuff the above address in, then
reference whats at the location? wont compile, tried many different
variations of this; any ideas appreciated.

unsigned char data = *((unsigned char*)0xFFF0000 E);

--

John Devereux

[suresh]

John Devereux wrote:

"Brad" <ro*********@ve rizon.net> writes:

Hi,

Am trying to read one byte at location 0xFFF0 000E in an embedded system.

I cast a pointer to int, then try to stuff the above address in, then
reference whats at the location? wont compile, tried many different
variations of this; any ideas appreciated.

unsigned char data = *((unsigned char*)0xFFF0000 E);

I don't see any compilation error in this code. Is it in global scope
by any chance?
Post the complete (minimal compilable) code.

Consider adding volatile to the typecast. This may not solve your
current problem though.

[Vladimir Oka]

suresh opined:

John Devereux wrote:

"Brad" <ro*********@ve rizon.net> writes:

> Hi,
>
> Am trying to read one byte at location 0xFFF0 000E in an embedded
> system.
>
> I cast a pointer to int, then try to stuff the above address in,
> then reference whats at the location? wont compile, tried many
> different
> variations of this; any ideas appreciated.
>
unsigned char data = *((unsigned char*)0xFFF0000 E);

I don't see any compilation error in this code. Is it in global scope
by any chance? Post the complete (minimal compilable) code.

You seem to have misinterpreted the attributions. The OP (Brad) did not
post any code. John then posted the line above (which looks OK to me,
too). We're still to hear from the OP whether it solves his problem.
Consider adding volatile to the typecast.

Another good idea for the OP.

--
Falling in love makes smoking pot all day look like the ultimate in
restraint.
-- Dave Sim, author of "Cerebus".

<http://clc-wiki.net/wiki/Introduction_to _comp.lang.c>

[suresh]

suresh wrote:

John Devereux wrote:

"Brad" <ro*********@ve rizon.net> writes:

Hi,

Am trying to read one byte at location 0xFFF0 000E in an embedded system.

I cast a pointer to int, then try to stuff the above address in, then
reference whats at the location? wont compile, tried many different
variations of this; any ideas appreciated.

unsigned char data = *((unsigned char*)0xFFF0000 E);

I don't see any compilation error in this code. Is it in global scope
by any chance?
Post the complete (minimal compilable) code.

Consider adding volatile to the typecast. This may not solve your
current problem though.

Oops... sorry. Don't consider my last statement unless the content of
that memory is volatile.

[Rod Pemberton]

"Brad" <ro*********@ve rizon.net> wrote in message
news:z_h4g.4277 $Sh.1325@trnddc 06...

Hi,

Am trying to read one byte at location 0xFFF0 000E in an embedded system.

I cast a pointer to int, then try to stuff the above address in, then
reference whats at the location? wont compile, tried many different
variations of this; any ideas appreciated.

This is compiler and environment specific.
(All examples are untested...)

Example 1) OW 16-bit DOS

unsigned char far *address;
unsigned char byte;
address=MK_FP(0 xFFF0,0x000E);
byte=*address;

Example 2) OW 32-bit DOS

unsigned char *address;
unsigned char byte;
address = (unsigned char *)(((unsigned long)0xFFF0)<<4 )+((unsigned
long)0x000E);
byte=*address;

Example 3) DJGPP 32-bit DOS (segmented memory model)

unsigned char byte;
byte=_farpeekb( _dos_ds,(((unsi gned long)0xFFF0)<<4 )+((unsigned
long)0x000E));
HTH,

Rod Pemberton

[Brad]

"Vladimir Oka" <no****@btopenw orld.com> wrote in message
news:wp******** ************@bt .com...

suresh opined:

John Devereux wrote:

"Brad" <ro*********@ve rizon.net> writes:

> Hi,
>
> Am trying to read one byte at location 0xFFF0 000E in an embedded
> system.
>
> I cast a pointer to int, then try to stuff the above address in,
> then reference whats at the location? wont compile, tried many
> different
> variations of this; any ideas appreciated.
>

unsigned char data = *((unsigned char*)0xFFF0000 E);

I don't see any compilation error in this code. Is it in global scope
by any chance? Post the complete (minimal compilable) code.

You seem to have misinterpreted the attributions. The OP (Brad) did not
post any code. John then posted the line above (which looks OK to me,
too). We're still to hear from the OP whether it solves his problem.

Consider adding volatile to the typecast.

Another good idea for the OP.

--
Falling in love makes smoking pot all day look like the ultimate in
restraint.
-- Dave Sim, author of "Cerebus".

<http://clc-wiki.net/wiki/Introduction_to _comp.lang.c>

Wow, you guys are fast. I was trying code on a different computer, didnt
have examples here, but was trying to force the literal memory address into
the pointer, then reference it, here the example simply references the
address, this is so awesome! Since Ive spent time having to not consider
any access to physical memory, this stumped me. I will go try this code out
soon. It will be reading an area of flash. The code module itself
references everything from an offset, this would be simply offset 0xE but
its always put into flash.

Its odd doing it this way but will work out perfectly. will try and post
results. Thanks for everyones input!

Brad

[Walter Roberson]

In article <87************ @cordelia.dever eux.me.uk>,
John Devereux <jd******@THISd evereux.me.uk> wrote:

"Brad" <ro*********@ve rizon.net> writes:

Am trying to read one byte at location 0xFFF0 000E in an embedded system.

unsigned char data = *((unsigned char*)0xFFF0000 E);

I went looking at the ANSI C89 reference thinking that was wrong, but
I was mistaken, and learned somethings along the way. It was not, though,
about the obvious question of whether a number can be converted to a pointer.

What I was looking at was whether the 0xFFF0000E constant had the
right type: I was thinking "Ah, but if int is only 16 bits, won't
that constant get truncated, seeing as it does not have a suffix?".
The C89 standard indicates, though, that an integer constant has
the smallest type out of a given list that will fit the numeric value.

And what I also found in the C89 standard was that the type list considered
is different for decimal constants than for octal or hex constants.
I had thought that all forms of constants were equivilent, but they
aren't.

On 16 bit int 2's complement systems, the decimal constant 65535
would be represented as type long int, but the hex constant 0xFFFF
would be represented as type unsigned int. That would imply that,
for example, on such a system, sizeof(65535) > sizeof(0xFFFF).

There's gotta be a good Obfuscated C trick in there somewhere ;-)
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)

[Brad]

"Walter Roberson" <ro******@ibd.n rc-cnrc.gc.ca> wrote in message
news:e2******** **@canopus.cc.u manitoba.ca...

In article <87************ @cordelia.dever eux.me.uk>,
John Devereux <jd******@THISd evereux.me.uk> wrote:

"Brad" <ro*********@ve rizon.net> writes:

Am trying to read one byte at location 0xFFF0 000E in an embedded
system.

unsigned char data = *((unsigned char*)0xFFF0000 E);

I went looking at the ANSI C89 reference thinking that was wrong, but
I was mistaken, and learned somethings along the way. It was not, though,
about the obvious question of whether a number can be converted to a
pointer.

What I was looking at was whether the 0xFFF0000E constant had the
right type: I was thinking "Ah, but if int is only 16 bits, won't
that constant get truncated, seeing as it does not have a suffix?".
The C89 standard indicates, though, that an integer constant has
the smallest type out of a given list that will fit the numeric value.

And what I also found in the C89 standard was that the type list
considered
is different for decimal constants than for octal or hex constants.
I had thought that all forms of constants were equivilent, but they
aren't.

On 16 bit int 2's complement systems, the decimal constant 65535
would be represented as type long int, but the hex constant 0xFFFF
would be represented as type unsigned int. That would imply that,
for example, on such a system, sizeof(65535) > sizeof(0xFFFF).

There's gotta be a good Obfuscated C trick in there somewhere ;-)
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)

Hey Thanks for that Walter, this is so interesting, and while trying the
solution, the compiler croaks for NO apparent reason at least to me,
1 unsigned char valIsaDot = 0;
2 unsigned char valBootVer = 0;
3
4 unsigned char *pBootVer = (unsigned char *)0xFFF0000E;
5 valBootVer = *pBootVer;
6
7
8 unsigned char *pBootDot = (unsigned char *)0xFFF0000F;
9 valIsaDot = *pBootDot;

The compiler says error at line 8 near 'unsigned' If line 8 and 9 are
removed, it compiles fine. There is nothing wrong with the spelling, it
simply wont allow this. On line 7 I add some extra task like int foo =0;
doesnt matter. If I take out the '=' on line 8 and have only the
definition? same error, line 8 near unsigned.


1// unsigned char valIsaDot = 0;
2// unsigned char valBootVer = 0;
3
4 unsigned char *pBootVer = (unsigned char *)0xFFF0000E;
5 unsigned char valBootVer = *pBootVer;
6
7
8 unsigned char *pBootDot = (unsigned char *)0xFFF0000F;
9 unsigned char valIsaDot = *pBootDot;

Do this? it compiles fine and works exactly right. (thanks again btw)
If there are no syntax errors, why does it refuse to accept the line 8
command before?