We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.
The 8051 memory management isn't the smartest way I can imagine to handle memory.
Back in the time when the architecture was invented, the memory architecture was pretty smart for the intended purposes and the expected price range of the chip.
Today, when throwing lots of transistors at a problem is cheap and acceptable, there are more convenient ways to deal with memory. Back then, that wasn't the case.
emme effe (a newcomer to the 8051) said, "I hate, I really hate this micro..."
Shivaram Cunchala (a newcomer to ARM from the 8051) said, "I just want to know if ARM is user friendly like our 8051"
;-)
Any new thing will always seem a bit bewildering until you get used to it!
That said, I don't think that something has to be difficult to be good. Agreed, KISS is the best way. However, how much do you learn from something easy? The 8051 memory management isn't the smartest way I can imagine to handle memory. Smart?, maybe not, but darn efficient when the '51 is used for the applications it is intendede for