That's actually a very good technique. I'm actually embarrassed for my e-mail now, as I can't believe I didn't think of that :/ Either way, to answer the questions. There is no real reason for this. I understand the constraints of an embedded device fairly well. I was mostly wondering out of curiosity. It was inspired by a redevelopment of a program, where I constantly run into situations where the first impulse is a malloc(), then a stop - think and redevelop a bunch of code. I'm busy making a base framework for all our applications while redeveloping one specific one, and the common behavior in them is difficult to define without dynamic data if you want a simple structure. I've had to make a few sacrifices so far, though I must say that without malloc things have been going pretty well. In the most severe cases I got away with using static (where I have declarations inside a function). Quintin Beukes On Tue, Oct 6, 2009 at 4:24 PM, Isaac Marino Bavaresco wrote: > Olin Lathrop escreveu: >> Quintin Beukes wrote: >> >>> I was hoping for some advice/corrections on dynamically allocating >>> memory. >>> >> >> Some compilers come with heap and dynamic memory management routines. = =A0Use >> them if they are there, or roll your own if you want or need to, but don= 't >> just go grabbing memory you think isn't in use. >> >> Why do you need to dynamically allocate memory anyway? =A0This is rather >> unusual in a small embedded system, and likely indicates big system thin= king >> on a small system. =A0I've only done on the fly real persistant memory >> allocation on a PIC once that I can remember, and in that case the memory >> being allocated was actually out on a ENC28J60 ethernet MAC/PHY with the= PIC >> keeping track of the allocated regions. =A0I have sometimes needed a tem= porary >> buffer and the like inside a single routine on a 18F. =A0In those cases = I have >> so far just temporarily appended the buffer to the data stack. >> >> What problem are you really trying to solve? >> >> >>> 4. I _assume_ the compiler will use ... >>> >> >> This sounds like really bad design. =A0Don't assume, know. =A0But even i= f you >> did know for sure, that only applies to this rev of this compiler. =A0Gu= essing >> where unused memory is without using the proper mechanisms to allocate i= t is >> heading for trouble. =A0For example, how do you know the data stack isn't >> allowed to grow into the left over memory? >> >> >>> Then chosen as follows: Any addresses above A9, and to accommodate >>> future changes, use any above 200, and carefully monitor my compiles? >>> >> >> Yuck! =A0That is really bad design. > > Indeed, your heap must be declared as a normal variable (big array of > char) so the compiler and linker locate it properly. If you just use an > address range you *think* is not in use then next time you link it, it > may be on top of some other variable. > > Then your allocator "cuts" chunks of it and gives to your application > (return the chunk address). > > See the sink I posted in my previous reply, it is exactly what you need, > and very well tested. If you need help to get started just send me a > message. > > Best regards, > > Isaac > > __________________________________________________ > Fa=E7a liga=E7=F5es para outros computadores com o novo Yahoo! Messenger > http://br.beta.messenger.yahoo.com/ > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist