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.
"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.
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.
Will I trade "coding efficiency" for "processor efficiency" in some cases, sure, but only where the adavnatge outweighs the disadvantage...
On the face of it that seems a remarkably balanced view coming from you.
...and the 'disadvantage' of not using LARGE can fit on a dime.
But then you spoil it with that nonsense.
Please try and accept that outside your little world of flashing LEDs (or whatever it is you work on) there are a whole bunch of people working on stuff where certain features provided by the Keil tools are not only *not disadvantageous* but positively *advantageous*. Your tiny sphere of experience only intersects slightly with the big picture. What's more, please also try and accept (and I realise that this will be hard for you) that even within your sphere of experience some of your long held beliefs are probably wrong. Even some of the rather more informed posters on this site have shown themselves to be well out of touch on occasion.
Even some of the rather more informed posters on this site have shown themselves to be well out of touch on occasion.
Is this your attempt to qualify yourself as a "rather more informed poster" ?