Hi, I am using calloc in a function to allocate memory to my array. This function writes to the array different number of elements each time the function is called. Here is my problem. Say for the first time function writes to all the 3 locations and next time it writes to only first 2 locations. After the second call, the 3rd memory locations still contains the value written by the first function call. I understand that is the way it works.But I want to know if there is a way to erase all the locations before calling the function again? Is there any built-in function available? Also when I print the values of array initially it doesn't print zeroes. I have read that calloc initializes the memory fields to 0's. Following is the function code.
function write_to_array(int value) { int xdata *ascii_value,i; ascii_value = calloc(3, sizeof (int)); for(i=0;value!=0;i++) { mod = value%10; c = mod+'0'; ascii_value[i] = toascii(c); value/=10; } }
Generally, an embedded system has to guarantee performance for a certain number of elements. Thus, you have to have memory available for the worst-case table size. Given that you have a guarantee, there's little reason to dynamically allocate that memory from a heap.
Dynamic allocation is only useful when two or more functions share the same resource, and the sum of the max consumption of each function exceeds the total resources available. If you just malloc() and free() and expect the arbitration to happen at run time, then you run the risk of being unable to operate at run time. Many embedded systems, unlike desktop apps, can't tolerate this sort of sudden and unpredictable failure, even if it's rare.
It's often useful to partition system resources between two functions depending on the application. Perhaps your system can support up to 32 widgets, or up to 16 gadgets, or any combination where a gadget takes twice the memory of a widget, say 16 widgets and 8 gadgets. You might use malloc() to chop up this heap into two pieces once at configuration time. This system would never call free() until it was reconfigured. So, the system is adjustable without recompiling, but still can guarantee performance of its configuration.
I also find it very common to dynamically allocate individual items from a particular pool -- say, message buffers. This is not a general malloc() function, though; there are many individual pools for particular purposes. Most often, the maximum size of such a pool is statically allocated, and items are of fixed size (meaning much less tracking overhead and time). But the usage of these pools is limited to a particular function of the code. There's no possibility that using a lot of items from one pool affects another. malloc() shares exactly one pool of memory between multiple functions, which is where the problems begin to creep in.
As far as linked lists and such are concerned, the 8051 has a pretty small address space. And, the architecture is poorly suited to handling pointers. Often, you'll be better off using a 8-bit or even 16-bit index into a table as the pointer in your lists, rather than an actual C pointer, which is to say memory address. It will often consume less storage, and also produce smaller and faster code than a textbook "struct MyStruct* next" implementation.
A mark/release concept is more appropriate for small embedded systems than 'alloc/free. Mr. Payson has an overview here (my apologies in advance regarding the link as this forum is having some difficulties with URLs lately):
www.htsoft.com/.../23148
Thank you all for making it very clear when to go for dynamic allocation. As most of you have said, I have changed my code to use an array of max size. Thank you Ramya
"Dynamic allocation is only useful when two or more functions share the same resource, and the sum of the max consumption of each function exceeds the total resources available."
Another case where dynamic allocation is useful is where the available resource is unknown at build time. This is quite rare in embedded systems, but very common indeed on PCs and the like.
Because standard 'C' textbooks tend to be written with general-purpose computer targets in mind (PCs, etc), they tend to take dynamic allocation as read
This is quite rare in embedded systems, but very common indeed on PCs and the like.
This contains another lesson about dynamic allocation:
It should only be used in cases where the program has a sensible option if the allocation fails. Your PC can bark "Not enough memory, stoopid." at you and exit the program. Your uC most likely can't.
Thank you all for making it very clear when to go for dynamic allocation
If it is 'clear' then why state it as the above, why not state
NEVER use dynamic allocation on a '51.
Since there will be exceptions to every rule, I am sure that there is one case in 1.000.000 where it is correct to use it, but I have not heard of it. That there will be one case in much less than 1.000.000 where it is used, does not make it right
There are features in Keil C51 that should not be there simply because they have to be "wresteled into the architecture" but Keil need to be able to state "ANSI compatible" so they are there.
Erik
I don't think you're in a position to comment on "ANSI compatibility" having never actually read the document in question.
If you'd like to give us all a laugh by inventing some examples to back up your statement please go ahead.
i posted "Keil need to be able to state "ANSI compatible" "
I don't think you're in a position to comment on "ANSI compatibility" having never actually read the document in question. The "document in question" is the Keil sales litterature, not the ANSI standard. And, contrary to your opinion, I have read that.
If you'd like to give us all a laugh by inventing some examples to back up your statement please go ahead. I'll gladly provide some fun, but examples of WHAT?.
However fun is one thing, derision is another and, it seems, you do not know the difference.
I'll gladly provide some fun, but examples of WHAT?.
Examples of features in Keil C51 that should not be there simply because they have to be "wresteled into the architecture" but Keil need to be able to state "ANSI compatible".
Examples of features in Keil C51 that should not be there simply because they have to be "wrestled into the architecture" absolutely: dynamic allocation function pointers most often (have yet to find a 'no'): floating point
The usage of the above in a '51 sigularily indicate the users inability to select a suitable processor for the job.
the unique structure of the 51 with 3,4,5 or 6 types of memory (depending on how you count) in combination with the Harward architecture makes it an extremely suited controller for the applications it is designed for. However any attempt to use it as a general purpose processor will, at best be clumsy, and sometimes even impossible (who wants to wait 5 minutes on an answer to "what is the log of 1.349264?")
If using floating point on a '51 makes sense, then it would equally well make sense to use a Pentium for a toy. Either would represent a bad processor choice.
Examples of features in Keil C51 that should not be there simply because they have to be "wrestled into the architecture"
As usual you've snipped the quote to change the meaning so I'll repost what you actually said:
Here's your first example of something to satisfy the above statement:
absolutely: dynamic allocation
Guess what? You're wrong. I'll leave it to you to read that nice new copy of the standard you've bought to find out why.
<usual "'51 ain't no PC" rubbish snipped>
There are features in Keil C51 that should not be there simply because they have to be "wresteled into the architecture" but Keil need to be able to state "ANSI compatible" so they are there. I have not "snipped the quote to change the meaning"
If you have a problem with english, let me try another way 1) There are features that The ANSI standard state a compliant C compiler must have. 2) To be able to state "ANSI C compatible", Keil need to include these feastures 3) Some such features are extremely combersome in the implementattion on the '51 architecture 4) Thus using such feature dramatically reduce the efficiency of the resulting code. 5) an example of such a feature would be dynamic allocation
now I have cut it in cardboard, and bent it in neon please elaborate on Guess what? You're wrong.
I'll leave it to you to read that nice new copy of the standard you've bought to find out why. I have no intention of purchasing a "nice new copy of the standard", till a problem should come up which what I have for a reference does not suffice. What I
I have no intention of purchasing a "nice new copy of the standard"
It's a pity, because if you did so (and read it, of course) you'd be able to avoid making false statements.
Dynamic allocation is not required to be implemented by a freestanding implementation.
ok 1) what is a 'freestanding implementation' ? 2) so I possibly missed one, what about function pointers which are a nightmare in the '51?
"1) what is a 'freestanding implementation' ?"
Aha - that's a term defined in the Standard...! ;-)
that's a term defined in the Standard will it cost me the price of the standard to find out or are you, Andy, going to tell me?