mBuino/RETRO - class instances and memory

[devhammer]

@Architect

You are trying to replace an object in the array with the pointer to another newly created object.

Your array is already initialized with instances of the MyGameObject using default constructor.

Yup…figured that out shortly after I posted.

I was able to completely eliminate my init code, since it was solely concerned with filling the vector of objects.

I also opted to do my own simplified implementation of the max function from since my needs were pretty simple, which saved another 0.2kB.

Thanks also for the debugging suggestion. Indeed, while I’m enjoying the challenge of a new language and platform, and for the most part find the limitations an opportunity to learn new techniques, there are times when working with mbuino and RETRO, or even Arduino, for that matter, reminds me of just how good we have it with Visual Studio and the rich debugging that’s available regardless of whether we’re doing desktop, web, or NETMF development.

I suppose I could get myself a JTAG debugger and set up a full dev environment for mbed, but I really like the simplicity of the browser-based IDE. Can’t have it all, I suppose.

[AndyA]

@devhammer

One additional question I have…probably one @ AndyA would be likeliest to know…the mbed platform compiler includes a Build tab for the program that lists the Flash and RAM used by the program. In my case, it shows 25kB Flash (78%) and 0.3kB RAM (4%) which seems quite low to me. The question: are these figures to be trusted? And I guess a secondary question…if I want to free up some of the flash, what are some strategies for doing that? I don’t really have any static consts defined, so I’m not sure where I’d look for Flash savings.

I think this has mainly been answered already but just in case…

The flash number can be trusted. As you’ve already seen from other posts the standard libraries are large, avoiding them is the main method to keep things small.

The RAM number is correct but only up to a point.
It only counts statically allocated memory, it doesn’t allow for anything created on the stack or the heap. So an array of objects that is global or static will be correctly counted, an array of pointers to objects won’t include the memory to store the objects, nothing created using new or malloc() will be taken into account. Similarly if you have a large number of local variables your stack could get very large but that won’t show up in the RAM usage number.

Just to add to the fun on other mbeds (e.g. the LPC1768) it’s possible to have 150% RAM usage and still work fine by forcing the use of other RAM blocks that the compiler will normally avoid.

[Jeff_ghielectroncs]

just skimmed through this thread again… my comment

[quote]For mbuino, the current heap size is 3072 bytes.[/quote] caught my eye. Many apologizes if it lead anybody down the wrong path… rather than type the wrong thing again, the authoritative comment is the source code
fragment from startup_LPC11xx.s for mbuino:

Stack_Size      EQU     0x00000400

                AREA    STACK, NOINIT, READWRITE, ALIGN=3
                EXPORT  __initial_sp

Stack_Mem       SPACE   Stack_Size
__initial_sp        EQU     0x10001800  ; Top of RAM from LPC11U


Heap_Size       EQU     0x00000000

                AREA    HEAP, NOINIT, READWRITE, ALIGN=3
                EXPORT  __heap_base
                EXPORT  __heap_limit

__heap_base
Heap_Mem        SPACE   Heap_Size
__heap_limit

the 3K limit (that I wrongly stated as heap) was from some experimental source code that I was using (as a a correct suggestion by Gus ) to debug a strange run-time error.