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
"an example I have not seen ANY "power user" in this forum that does not deride malloc() and the associated when used on the '51," I use malloc occasionally depending on the application. What's you're problem with it?
Because the size of RAM in an embedded system is almost always fixed & known at compile time (especially on systems suited to an 8051), there is seldom any point in dynamic allocation. But it always adds an overhead - and the question of what to do if a malloc call fails...!
what to do if a malloc call fails This is usually the biggest issue for my projects. I typically have to guarantee that the system supports M widgets and N thingies. And the system can't just not work, or throw up a dialog box and reboot. You pretty much have to guarantee before turning on the power that enough memory is available to do the worst-case job. The biggest exception is when the design has some acceptable tradeoffs. Maybe it can accomodate up to M widgets max, and N thingies max, but you can configure it to have m < M widgets and n < N thingies in some combination. In this case, you might consider the partitioning to be "dynamic" in that it's not pre-allocated static memory. But the code still wouldn't likely be creating individual widgets and thingies on the fly. It would just allocate the max size tables according to the configuration. It's fairly common for me to dynamically allocate an entry out of one of those tables. But that's not a call to malloc(), but rather some other routine that tracks usage of just that table. You can argue that using malloc() results in less work and less code than writing a bunch of individual allocators. On the other hand, a general-purpose memory allocator is almost always much slower and less efficient than special-purpose ones that can allocate fixed block sizes, and particularly known ones. And rarely are there many different types of objects (records, message buffers, whatever) that need to be allocated.
"Because the size of RAM in an embedded system is almost always fixed & known at compile time (especially on systems suited to an 8051), there is seldom any point in dynamic allocation." Picture the scenario where you need a chunk of memory that doesn't need static storage duration but requires a lifetime greater than that of automatic data within a function. In this situation dynamic allocation allows more efficient use of memory than can be achieved with data overlaying. "But it always adds an overhead" Sure - but that's only a concern to some applications. " - and the question of what to do if a malloc call fails...!" As you pointed out above the memory available is generally known. Why would you try and allocate more memory than exists?
Picture the scenario where you need a chunk of memory that doesn't need static storage duration but requires a lifetime greater than that of automatic data within a function. In this situation dynamic allocation allows more efficient use of memory than can be achieved with data overlaying. Not necessarily. If you need that memory at any time you WILL need it free (unused) when you do not need it. As you pointed out above the memory available is generally known. Why would you try and allocate more memory than exists? apples and oranges this should read "As you pointed out above the total memory available is generally known. Why would you try and allocate more unused memory than exists" The amount of unused memory is not easily "known" Erik
"Not necessarily. If you need that memory at any time you WILL need it free (unused) when you do not need it." That is exactly the point of using dynamic memory allocation. You free it when you no longer need it, then you can re-use it. "The amount of unused memory is not easily "known"" 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.
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.