AW60 & Codewarrior 6.0 for Microcontrollers - ansii.lib question

[v_dave]

Hello All,

Before I begin I already started an SR 1-422477913 a> but I am hoping another user has had this issue and might be able to provide an answer a little quicker.

My processor is a 9S08AW60 (2048 Bytes RAM, 64K ROM) and I am using CW 6.0 for Microcontrollers.  I have purchased a thrid party embedded GUI library for the LCD I have connected and I am running into a problem with the amount of RAM being used.  currently it appears I am using 2447 Bytes of RAM, obviously too much.  In trying to figure out where I can cut back I noticed that CW seems to be the big memory hog not the GUI library. 

CW links in a library called ansii.lib.  It appears that this lib is allocating 2018 bytes of RAM.  When the processor only has 2048, well that does not leave much for anyone else.  Does anyone know how to reduce how much RAM this lib function is using?

a>

[bigmac]

Hello Dave,

My understanding is that the code and data sizes listed against a library file (and probably any other source files) represent the total resources required by the library if all functions were to be utilised.  Since this is unlikely to be the case for the ANSI library, the unused functions will not be linked, reducing the resources actually consumed by the library functions.

Normally, you would consult the project.map file to see actual allocations, but I think you will first need to get a successful compile and link of your code.

Regards,

Mac

Message Edited by bigmac on 2008-02-15 12:55 PM

[CompilerGuru]

To get a successful link, just tweak the prm temporarily and provide more RAM. But actually even when the linking fails, the linker is still emitting a (partial) map file which lists everything which was allocated before the failure happened.
The only thing which comes to my mind which uses more than a few bytes of RAM is malloc, the buffer there can (and obviously should) be adapted to the actually available RAM.
See libdefs.h, LIBDEF_HEAPSIZE.
If possible, I would not actually use dynamically allocated memory on a small chip though.

Daniel

[v_dave]

Hello All,

First, thanks for the responses this was all good info.

After looking at the partial .map that was generated I see th following line:

*********************************************************************************************
OBJECT-ALLOCATION SECTION
     Name               Module                 Addr   hSize   dSize     Ref    Section   RLIB
---------------------------------------------------------------------------------------------
MODULE:                 -- HEAP.C.o (ansiis.lib) --
- PROCEDURES:
     _heapcrash_                                  0'Error      16      22       0   .text      
- VARIABLES:
     _heap_                                       0'Error     7D0    2000       0   HEAP_SEGMENT

It appears that the compiler is allocating 2000 bytes to the heap.  I do not use malloc functions when I am using an 8-bit micro with 2K of RAM, this usually can cause more problems than it's worth.  So now the question is where can I change _heap_ to a smaller value?

I looked in the Processor Bean but I don't see a heap setting. I tried to change libdefs.h but did not change anything after a recompile.  I am not finding it in the CW docs but is there a compiler switch I could use?

[v_dave]

OK, I was able to directly adjust the .prm file to add some "virtual memory" ;o) and now I do not get a linker error and I am able to see a full .map file.

It is defenitely the heap that is sucking up all the RAM.

Code:

.startData                        14     R     0x193D     0x194A   ROM.init                            221     R     0x1860     0x193C   ROMHEAP_SEGMENT                    2000   R/W       0xED      0x8BC   RAM.common                          168   R/W      0x8BD      0x964   RAM.stack                            64   R/W      0x965      0x9A4   RAM.copy                              2     R     0x28D1     0x28D2   ROMSummary of section sizes per section type:READ_ONLY (R):        10A9 (dec:     4265)READ_WRITE (R/W):      915 (dec:     2325)NO_INIT (N/I):          8B (dec:      139)

 
I have tried to change:

//#define LIBDEF_HEAPSIZE 2000
#define LIBDEF_HEAPSIZE 500

in libdefs.h but even when I rebuild the application for some reason _HEAPSIZE is not getting updated.  Anyone know how I can force the updated libdefs.h to be included in a recompile?

[bigmac]

Hello Dave,

If the code you have written does not use the heap functions, I would assume it is the third party code that does .   I would expect that the third party supplier should be able to specify the total resources, including heap and stack size, that the software requires.  This will determine whether the software is actually compatible with a particular device.

Regards,

Mac

[CompilerGuru]

The map file shows the dependencies, so when searching for _heap_ and following all dependencies, it should be easy to spot where the dependency is from.
Changing libdefs.h on its own does not help as the HEAP.C is compiled as part of the library.
So there are these two ways:
- add heap.c to your project and make sure it links before the ANSI lib in the link order.
I think this may cause a linker warning about the different sized _heap_.
- rebuild the ANSI library, there is a mcp in lib/hc08c/ to do that. Note that this will rebuild the shared library used for all projects.

With a local libdefs.h and the search paths setup that this one is found first, the first method can be done without changing the library.

Daniel

[v_dave]

Hello All,

Thanks for the info from everyone.  I think I resolved it and the solution was from Bigmac.  I unknowingly turned on a feature in the GUI lib that uses malloc() which caused the heap to be allocated. 

I am still a little confused about the role that libdefs.h plays.  According to the Compler_HC08.pdf

Memory Management - malloc(), free(),

calloc(), realloc(); alloc.c, and heap.c

File alloc.c provides a full implementation of these functions. You must specify heap

location, heap size, and heap overrun processes.

Address all of these points in the heap.c file. View the heap as a large array with a

default error handling function. Feel free to modify this function or the size of the heap to

suit the needs of the application. Define the heap size in libdefs.h,

LIBDEF_HEAPSIZE.

I understand what Daniel is saying but the documentation tells something different. 

So I tried the first method and I do get a warning "L1919: Duplicate defination of _heap_. Ignoring defination from heap.c.o(ansiis.lib), using definition from heap.c.o"  Other than this warning it seems to fix the allocation issue.

Anyways I will disable the GUI function that usues malloc() until I understand better how much _heap_ space I need to allocate.