Re: Trying to understand the workings of a Memory Mapped I/O

David Bardon wrote:

> Las,
>
> "Las" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > Here is the sample area:
> >
> > #define P0 ((*(__R volatile unsigned char *)(unsigned char)0x0))
> > #define P1 ((*(__R volatile unsigned char *)(unsigned char)0x1))
> > #define P2 ((*(__R volatile unsigned char *)(unsigned char)0x2))
> > #define P3 ((*(__R volatile unsigned char *)(unsigned char)0x3))
> >
> >
> > How would you describe what this is or does? If someone could break it
>
> down
>
> > so I could understand what is going on I would be in your debt.
>
>
> Las,
>
> Here's my take on it.  Firstly, these are C language preprocessor macro
> definitions. The preprocessor's job is to substitute the token P0 with the
> expression given in the definition;
>        ((*(__R volatile unsigned char *)(unsigned char)0x0))
> The C preprocessor is, in essence, a text substituter.
>
> As to the meanings of the definitions, it can be analysed by proceeding from
> the right towards the left.  The numerical values, 0x0, 0x1, etc. are
> integer constants.
>
> Each of these constants is typecast to an unsigned char.  This has two
> effects:
> 1.  To take only the least signifigant 8 bits of the integer constant.  In
> the case of your
>      values, this effects no change.  It would if the values exceeded 0xFF.
> 2.  Suppress any sign extension.  It's the "unsigned" that does this. In the
> case of
>     your values, there is again no effect.
>
> The typecast preceding this; "volatile unsigned char*" means regard the
> expression to the right of this typecast as a pointer to an unsigned char.
> i.e. the expression is to be regarded as an address.
> The "volatile" word tells the compiler not to assume that the unsigned char
> pointed to will retain its value between accesses; i.e. it might be changed
> by external events.
>
> The "__R" qualifier is non-standard and I don't know what it means.  I would
> guess it might mean register, as the names P0, P1, etc. seem to be register
> names.
>
> Finally the '*' preceding this typecast means the contents of the address
> location;
> the value at the specified address.
>
> P0,P1,P2,P3 are the names of the ports on a standard 8051 processor, but
> their
> respective addresses are 0x80, 0x90, 0xA0, 0xB0 respectively, so if the code
> were to refer to an 8051, there leaves something about the definitions yet
> to
> be understood!

Good analysis.  My guess is that the locations 0x1... are loaded 
with the real P0, ... data by "another process" - in other words
they are letting this process think it is dealing with the ports. - RM