I am using P89V51RD2 and I want a description about the memory models. I want to use the whole 1KB RAM of the controller. I tried to search for the memory model, but was confused by the data given on the page below.
www.esacademy.com/.../c02.htm
It says that you can only access 256 bytes of RAM even though you use LARGE model. Can anyone figure it out?
"I am using P89V51RD2 and I want a description about the memory models."
For definitive details about any product, always start with the product's own manuals:
http://www.keil.com/support/man/docs/c51/c51_le_memmodels.htm
http://www.keil.com/support/man/docs/c51/c51_le_memareas.htm
"confused by the data given on the page below."
Well, that diagram certainly looks confusing - misleading, even!
For a start, it's not to scale. It also doesn't make clear which address spaces are distinct - like CODE and XDATA - and which physically overlap - like XDATA and PDATA, or DATA, the Register Banks, and the lower end of IDATA.
Again, you'd probably be better to go back to the original source documents - the so-called "bible" for the 8051:
Chapter 1 - 80C51 Family Architecture: www.nxp.com/.../80C51_FAM_ARCH_1.pdf
Chapter 2 - 80C51 Family Programmer’s Guide and Instruction Set: www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf
Chapter 3 - 80C51 Family Hardware Description: www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf
You might find that Figure 2 on p2 and Figures 6-8 on p3 of Chapter 1 give a better illustration of the memory spaces...
"It says that you can only access 256 bytes of RAM even though you use LARGE model."
I hope it doesn't actually say that - because that is complete nonsense!
You might find this tutorial more helpful:
www.8052.com/tutmemor.phtml
It does make the common mistake of implying that "CODE" is synonymous with "ROM", and "XDATA" is synonymous with "RAM". (In the vast majority of cases, CODE space will, in fact, contain ROM and XDATA will, in fact, contain RAM - but there is absolutely nothing in the architecture that requires this).
It also doesn't mention the possiblity of on-chip XDATA.
even though you use LARGE model.
The LARGE model makes the whole thing slow and cumbersome, use the SMALL model and assign XDATA to the rarely used variables.
Just for edification try writing a small program, compile it SMALL, look at the generated assembler, then compile it LARGE and look at the generated assembler, you will be amazed by the difference.
Of course, if you consider convenience more important than efficiency, go ahead and use LARGE.
Erik
You've been quite good for a while but I see you're beginning to slip back into your old ways...
The OP said:
It says that you can only access 256 bytes of RAM even though you use LARGE model.
But you snipped it to:
Don't do that. Selective quoting to distort the meaning is distinctly unprofessional.
Here's what happened the last time you went off on one of your 'large model inefficiency' rants:
http://www.keil.com/forum/docs/thread10196.asp
Given that 'efficiency' is your obsession how do you justify coding in 'C'? For a bit of fun I've rewritten the rest of your post:
'C' makes the whole thing slow and cumbersome, use assembler instead.
Just for edification try writing a program in assembler, look at the code size, then rewrite it in 'C' and look at the generated assembler, you will be amazed by the difference.
Of course, if you consider convenience more important than efficiency, go ahead and use 'C'.
Ah, but a lot of people would not gain anything by going from C to assembler ;)
mr smoked sar5dine: Oddly enough (if YOU took the time to investigate befor spewing out your bile, you would know) the inefficiency from using LARGE is most prevalent for C code. You BABBLE about the inefficiency of C, yes you can write =more efficient code in assembler when needed. However, the loss of efficiency using C (using C is a major timesaver) does not need the added overhead from using LARGE (which saves virtually no time). Will I trade "coding efficiency" for "processor efficiency" in some cases, sure, but only where the adavnatge outweighs the disadvantage and the 'disadvantage' of not using LARGE can fit on a dime.
"adavnatge"
Careful, I think you just broke your keyboard :)
The OP is happy to get access to his memory. We don't know what for, or if memory model differences matter.
Erik,
I'm going to count to ten very slowly ...
Consider ALL the previous comments concerning large and inefficiency before going off on one of you rants again please.
Consider ALL the previous comments concerning large and inefficiency before going off on one of you rants again please. that the LARGE model makes the processor work in a slow and cumbersome way is not a 'rant' but a FACT.
I even gave mr. Smoked Sardine et al a bit of leeway: Of course, if you consider convenience more important than efficiency, go ahead and use LARGE.
"that the LARGE model makes the processor work in a slow and cumbersome way is not a 'rant' but a FACT."
Oh dear, you don't appear to know the meaning of the word relative do you, huh??!!
Anyway, after my slow ten second delay I can type with a little more reserve.
Fortunately I consider myself to have sufficient experience so say that I can read your responses and know they're occasionally biased, provocative or just plain wrong.
The thing that concerns me is that less experienced users of this forum (i.e., the ones that really could gain from it) might read your posts, see they're written in manner that appears authoritative and believe that you are right.
For their sake, please consider your responses more carefully.
View all questions in Keil forum