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.
Hello, i am using 8052 in my project and according to datasheet the data memory is 256 bytes but in my code if i exceed 128 bytes the code is not compiled do i need to use it as x data memory? please help
I realise you are unfamiliar with dynamic memory allocation so I'll explain: When memory is allocated you specify the number of bytes required, and there is a fixed overhead associated with each allocation. So, the amount of memory used *is* easily known. you realize diddlysquat. You are babbling about memory being made available, that was never the issue, the issue is memory available to be made avalilable. The amount of memory used is NOT known. if you are in the middle of a function called by a functio called by main you have the globals, the locals in main the locals in func1 and the locals in func2 subtracted from available memory. We are discussing available memory NOT how much you try to make avalible with the PC feature used on a '51. I ma VERY "familiar with dynamic memory allocation" and DO use it where appropiate, but I would never dream about using it on a device with scarce resources. Erik
I said: "I realise you are unfamiliar with dynamic memory allocation so I'll explain: When memory is allocated you specify the number of bytes required, and there is a fixed overhead associated with each allocation. So, the amount of memory used *is* easily known." You replied: "you realize diddlysquat. You are babbling about memory being made available, that was never the issue, the issue is memory available to be made avalilable." Not only are you rude, you are wrong. In the paragraph you quoted I am describing how we know how much memory is used when it is allocated using malloc() and friends. I am *not* talking about "memory being made available". "The amount of memory used is NOT known. if you are in the middle of a function called by a functio called by main you have the globals, the locals in main the locals in func1 and the locals in func2 subtracted from available memory." The 8051 has distinct memory spaces. In a typical scenario the variables you describe would be located in the 'data' space, dynamic ally allocated memory would be located in the 'xdata' space, hence the memory occupied by automatic and static variables would *not* need to be subtracted from the pool available. "We are discussing available memory NOT how much you try to make avalible with the PC feature used on a '51." malloc() and friends predate the PC by a long way. They are features of the standard C library, not specific to any one platform. "I ma VERY "familiar with dynamic memory allocation"" Quite frankly that does not seem to be the case. "but I would never dream about using it on a device with scarce resources" You are blinkered by your lack of understanding.
Not only are you rude I consider the assumption "I realise you are unfamiliar with dynamic memory allocation" very rude.
In the paragraph you quoted I am describing how we know how much memory is used when it is allocated using malloc() and friends. I am *not* talking about "memory being made available". whatever, you are totally missing the point. the issue is neither "how much memory is used" nor "memory being made available" BUT how much memory available at the call.
You are blinkered by your lack of understanding. and so are you. when are you going to understand: The '51 ain't no PC
"I ma VERY "familiar with dynamic memory allocation""
Quite frankly that does not seem to be the case. now, who is being rude now.
You, Sir evidently am not "VERY "familiar with dynamic memory allocation", using it on the '51 architecture indicate total ignorance of the effect of archiecture on this call.
Erik
"I consider the assumption "I realise you are unfamiliar with dynamic memory allocation" very rude." It was merely an observation based on your statements which clearly show that you don't understand how dynamic memory allocation works. "whatever, you are totally missing the point. the issue is neither "how much memory is used" nor "memory being made available" BUT how much memory available at the call." Surely you can understand that if you know how much memory has been used from a fixed size pool you know how much memory is available? It's simple arithmetic. "and so are you. when are you going to understand: The '51 ain't no PC" I don't know why you keep saying this - it is quite obvious that an 8051 is not a PC. Is this some sort of catchphrase? "now, who is being rude now" I have no desire to be rude, I'm merely making an observation. "You, Sir evidently am not "VERY "familiar with dynamic memory allocation", using it on the '51 architecture indicate total ignorance of the effect of archiecture on this call." You're clearly a very opinionated chap with very fixed ideas about what is right and what is wrong. I've put forwards a scenario where dynamic memory allocation can be a good thing even in an 8 bit microcontroller environment, for one reason or another you either cannot or will not try to understand it. Well, that's fine by me - I give up. By the way, there's really no need to call me 'Sir'. It has quite a nice colonial touch but is probably redundant in the 21st century. Have a good weekend.
Surely you can understand that if you know how much memory has been used from a fixed size pool you know how much memory is available? It's simple arithmetic.
again you talk apples I talk oranges
If you use malloc to allocate 1234 bytes, YES you know you have allocated 1234 bytes. What I am trying to state is that you do not know at the time of the malloc call if the 1234 bytea are available.
One issue I have forgotten is that with dynamic memory allocation you get one added level of indirection (one thing the '51 architecture is terrible at)
My approach to "dynamic memory allocation" for the '51 (I gladly use malloc() when coding for a PC) is to have workbuffer[] together with a flag "workbuffer in use" That way you can share the memory space and avoid more indirection than needed.
You have a good weekend too.
Sorry but you fail to see the down sides. First. Fragmentation may cause you to have less usable memory then free memory. The PC "Resorces Low message" will not be OK for even a TV set. Embedded system may need to work for years between reboots. 2. You get to INSURE that there is enough memory. Static allocations are insured by the fact it builds. 3. Memeroy leaks. 4. Overhead the malloc code takes up space. The alloc / free takes up time. Finally, Beginners use it becuase that is what they used on the PC. They do not even try to avoid it. They do not know there are trade-off involved. If you do need it on a 8052 you should have enough experience to know it is the last choice. Very few 8052 project really need it. Or should.