I have this code:
typedef struct _DLL_struct { unsigned char DLL_type; unsigned char DLL_lenght; unsigned char DLL_data_begin; } DLL_struct; unsigned char xdata FskRxBuf[MAX_SIZE_BUFFER]; void main(void) { DLL_struct *DLL_ptr; // pointer to cast on the buffer unsigned char xdata chacksum_rx; DLL_ptr = (DLL_struct *)FskRxBuf; // cast the struct to the buffer checksum_rx = *(&DLL_ptr->DLL_data_begin + DLL_ptr->DLL_lenght); // read the received checksum }
I tried to define a struct pointer and cast it on a plain char buffer to obtain access to the buffer using the fields of the structure. I run the code on a debugger and get a problem with the address of the structure fields. Say that FskRxBuf begins at 0x0292, the debugger tells me that the expression &DLL_ptr->DLL_data_begin is 0x92 and not 0x0292 like I thought. Where is my mistake?
I should probably not answer this, since I don't work with the C51 compiler.
However, an interesting thing is that FskRxBuf resides in xdata, but you typecast to a pointer type that does not mention xdata.
Another thing to think about - even if it doesn't affect the C51 - is that typecasting between a raw buffer and a struct can break alignment requirements.
Yep, I know about alignement, I had a lot of experience on that issue in the past, but thanks to nominate it.
About the real problem: you're right, I don't mention xdata on the pointer definition, 'cause I hadn't read the generic and memory specific pointer section yet! I hate, I really hate this micro...
For the record: I changed the pointer definition into:
DLL_struct xdata * data DLL_ptr; // pointer (in data) to cast on the buffer (in xdata)
and all works fine.
Except the fact that my debugger continues to show me the expression
&DLL_ptr->DLL_data_begin = 0x92
but I bet it's a flaw of the debugger (unfortunately it wouldn't be the first one...)
Thanks a lot for your help.
I hate, I really hate this micro... what you are relly saying is: "I hate, I really hate having to think..."
Erik
The '51 with all its quirks is, for many applications, the best processor you can choose. Now, the contrary, choosing the '51 for the wrong application is, of course, just as wrong.
are we getting emotional, erik :) effe is simply expressing frustration that he needs to learn so much and that the material less than evident. he will fall in love with the 51 soon, I'm sure...
nothing emotional, just that hating something because it is not easy will never get you anywhere.
I forgot a smiley in my previous statement. That said, I don't think that something has to be difficult to be good. The 8051 memory management isn't the smartest way I can imagine to handle memory. But I have to admit I'm not so into this micro to understand what could be the idea behind that. Just don't hate me for that, please.
"we love you, emme!"
Two reasons for the memory layout: - Minimal transistor count. - Small instructions.
For an 8-bit processor without real 16-bit registers, a full 16-bit address is no fun at all. Intel wanted as large part of the application as possible to use 8-bit addresses. Remember that the original C51 did not have any processor cache to handle the extra ticks required to access one or more extra bytes of instruction data from a very, very slow memory.
View all questions in Keil forum