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.
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.
Where do I say anything to the contrary? Please provide a quotation, taking care to do so accurately.
here in your retort to my suggestion of not using large: 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. the memory model is totally irrelevant in assembler, it only affect C. BTW I have never "looked at the generated assembler", if C is too slow for a given function, who cares what "the generated assembler" looks like, I just reqwrite it in assembler.
here in your retort to my suggestion of not using large:
You see? No reference whatsoever to memory model. Please try to read and understand posts before you reply to them.
View all questions in Keil forum