Now I'm doing a embedded project using HC08, and I tried to use the queue structure. Acutully I try to assign some space in the ram using malloc func, the compile is right , anyway, I cant link it. The error says " Out of allocation space". That's strange, because I assign enough for the ram, so what problem can cause this occur?
RGS
I think it is because the HEAP_SEGMENT is too big "2000" see the map following .abs_section_69 2 N/I 0x69
0x6A .absSeg117 .abs_section_1806 2 N/I 0x1806 0x1807 .absSeg118 .abs_section_1814 2 N/I 0x1814 0x1815 .absSeg119 .abs_section_fffe 2 R 0xFFFE 0xFFFF .absSeg120 .bss 4 R/W 0x7F 0x82 RAM HEAP_SEGMENT 2000 R/W 0x83 0x852 RAMSummary of section sizes per section type: READ_ONLY (R): 2 (dec: 2) READ_WRITE (R/W): 7D4 (dec: 2004) NO_INIT (N/I): 8B (dec: 139) compare with the prm NAMES END /* CodeWarrior will pass all the needed files to the linker by command line. But here you may add your own files too. */
SEGMENTS /* Here all RAM/ROM areas of the device are listed. Used in PLACEMENT below. */ ROM = READ_ONLY 0x4000 TO 0xFFAF; Z_RAM = READ_WRITE 0x0070 TO 0x007E; RAM = READ_WRITE 0x007F TO 0x086F; ROM1 = READ_ONLY 0xFFC0 TO 0xFFCB; END
PLACEMENT /* Here all predefined and user segments are placed into the SEGMENTS defined above. */ DEFAULT_RAM INTO RAM; DEFAULT_ROM, ROM_VAR, STRINGS INTO ROM; /* ROM1 In case you want to use ROM1 as well, be sure the option -OnB=b is passed to the compiler. */ _DATA_ZEROPAGE, MY_ZEROPAGE INTO Z_RAM; END
STACKSIZE 0x50
so any idea about correct this problem, thanks
In article , caicai writes
Do NOT use MALLOC
The problem is you do not have enough physical space.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
There are times when malloc is appropriate -- if you only use it at startup (this is a good technique for reusable code), or if it'll only get used in response to service or engineering activity where you can guarantee a power cycle following its use.
I very much doubt that this is one of those times, though.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" gives you just what it says. See details at http://www.wescottdesign.com/actfes/actfes.html
I agree. However most coding standards (especially those tending to high reliability) will ban it. As the exceptions are few and far between and should only be done by some one who knows what they are doing I will settle for a blanket ban.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
The place where I do use malloc is in the startup code that I write when I build a version of an embedded firmware compiled instead to run on a PC - I make a malloc call to grab something comparable to the available RAM on the embedded target, and then let my manual allocation scheme chop that up instead of the fixed based address it uses when running on the real embedded target.
I am running into a problem with this on uCLinux though - the tcp calls don't like it when I pass them a pointer to a buffer located in memory which was reserved by telling the O/S that the physical memory is smaller than it really is.
... snip ...
Please limit your line lengths to 72 (67 is better). This will avoid evil line breaking, such as the above.
-- "Vista is finally secure from hacking. No one is going to 'hack' the product activation and try and steal the o/s. Anyone smart enough to do so is also smart enough not to want to bother."
Why ban malloc(), it would be much simpler to just ban free( :-).
If the system still works after the hardware burn in period of say a few days or weeks, then malloc has been used in a responsible way (if used at all).
Paul
In article , Paul Keinanen writes
How long? Embedded systems run for years. I once worked on a system where we had a memory leak... It was estimated that if it was run in a particular configuration it would cause a problem after 10 years continuous use. We had to find the problem.
Many embedded systems are safety/mission critical.
That's the 90/10% rule 90% of the programmers think they are the
10%that are experts and the rules don't apply to them.......-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Blame my posting host's provided editor ;-)
Cute, but not safe.
VERY VERY DANGEROUS THINKING!
A hardware burn-in enviornment proves nothing about the behaviour of the software when subjected to real-world input.
Many embedded systems (especially non-redundant systems) are often required to run for years without a reboot, so it is out of the question that the system could fail due to dynamic memory fragmentation. If you do not use free() the dynamic memory can not be fragmented, so no need to worry about it :-).
However, in large systems requiring high availability and running for years or decades, the hardware failure rates will force the use of redundant hardware, in which some rare scheduled reboots can be allowed.
When people talk about "memory leaks", they usually refer to a situation, in which some memory resources are freed, but not all resources and then the full set of resources are then reallocated.
If you never use free(), you should not have those memory leak problems, not at least in the traditional sense. Of course, if the program is faulty and allocates more memory each time a command is entered, then it is quite likely, that the problem becomes visible very fast, due to lack of free dynamic memory, but it certainly will not cause any memory fragmentation problems after a few months or years.
Paul
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.