Hi,

I'm currently working on a program using my CMDB lib which uses an array of object (each of wich will malloc some strings).

At a certain point the prompt does not appear anymore. When i disable one of more commands (so the table is a bit smaller, things start to work again).

As i suspect the heap size, is there a way to increase it?

wvd_vegt

The heap does not have fixed size, but shares RAM with the stack and they grow towards each other. See here for the pictures: http://mbed.org/handbook/Memory-Model

I would suggest you to try to reduce heap usage. Use static/global objects, use constant strings if possible, use automatic (stack) variables which are destroyed on exit from the function, and so on. For example, instead of using dynamic allocation for your cmd structs, you can make them static:

struct cmd {
    const char *cmdstr;
    int  subs;
    int  cid;
    const char *parms;
    const char *cmddescr;
    const char *parmdescr;
};

static const cmd MACRO = { "Macro", GLOBALCMD, CID_MACRO, "%s", "Define macro (sp->_, cr->|)", "command(s)" };

This will create the same structure as before, but all string pointers will be static and pointing into ROM memory, saving RAM for other purposes.

I would also probably use a simple array for the commands instead of vector. If you feel you need to change the command list at runtime, you could use a vector to keep them inside Cmdb, but you don't really need a vector when initializing it. So, for example:

static const cmd c1  = { "Test", SUBSYSTEM, CID_TEST, ""  , "* Test Subsystem", ""};
static const cmd c2  = { "Int" , CID_TEST , CID_INT , "%i", "* Int as parameter" ,"dummy"};

struct cmd my_cmds[] = { c1, c2, COMMANDS, BOOT, ECHO, ..., IDLE, HELP };

#define MY_CMD_COUNT sizeof(my_cmds)/sizeof(my_cmds[0]) // a trick to count number of items in an array

Cmdb cmdb(serial, my_cmds, MY_CMD_COUNT, &my_dispatcher);

Again, this will store the initial list of commands in ROM instead of wasting RAM for transient lists.

Hi Igor,

Thanks, food for thoughts.

My C++ is not that best so I tend to keep it simple. The problem with an array was that the commands are patially internal to cmdb and partially app supplied. That was my reason to choose a vector as it's std C++ and can be resized easily.

Some minutes (and lots of typing) later:

It safes a heck of a lot of memory, so thanks Igor. I opted for keeping the vector but defining all stuff as static const as possible. My largest memory block grew from little under 1K back to 22K. I also got rid of some defines that where annoying me in the process.

I only had the rewrite the table definition to use {} initialisation instead of the cmd construtor and remove the two cmd constcrutors form code.

Again thanks!!

wvd_vegt

Glad it helped!

Hi Igor,

FYI Googleing around I found two interesting heap related functions which might solve the malloc failures (and according to these realview function output they are supported by mbed).

1) __heapstats((__heapprt)fprintf,stderr);

17892 bytes in 2 free blocks (avge size 8946
1 blocks 2^8+1 to 2^9
1 blocks 2^13+1 to 2^14 

2) __heapvalid((__heapprt)fprintf,stderr, 0);

alloc block 1000150c size  18
alloc block 10001524 size  18
alloc block 1000153c size  18
alloc block 10001554 size  18
alloc block 1000156c size  18
alloc block 10001584 size  18
alloc block 1000159c size  18
alloc block 100015b4 size  18
alloc block 100015cc size  18
alloc block 100015e4 size  18
alloc block 100015fc size  18
alloc block 10001614 size  18
alloc block 1000162c size  58
alloc block 10001684 size  18
alloc block 1000169c size  18
alloc block 100016b4 size  10
alloc block 100016c4 size  18
alloc block 100016dc size  a0
alloc block 1000177c size  58
alloc block 100017d4 size  18
free block  100017ec size 1f8 next=1000248c
alloc block 100019e4 size 608
alloc block 10001fec size 4a0
free block  1000248c size 43d4 next=00000000
------- heap validation complete

Together with __current_sp() it will give much insight into the heap allocation and stack collision.

See [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0171b/Cihhgjad.html]

wvd_vegt