I am working on a datalogger based on the Mbed. And I seem to be running into memory issues causing my Mbed to malfunction silently.

My program has grown quite a bit in size as I am using the following parts.

FAT-filesystem for a big persistent ringbuffer. Memory based ringbuffer acting as cache for the FAT filesystem. (6000 bytes) Netservices to connect to the internet and offload data. Custom I2C communication polling a range of sensors.

I have had to increase the memory of the Netservices library to get speeds above 3K/second. By increasing it from 2000 to 6000 bytes i achieve a throughput arund 30KB/second.

Any idea on what I can do to release more memory for my application to run more smooth?

Kind regards

Jesper

If you have not already done so, you might try adding Segundo's AvailableMemory library to your program, so you can print out exactly how much RAM you have to spare.

It looks like you are running on fumes :-)

Just curious - why the 6000 byte memory-based ringbuffer? Is data coming too fast to be written directly to the filesystem?

I ran into a similar problem with a similar application. The silent crash on memory allocation was allegedly fixed in a past library update (to return NULL as it should), but I can still reliably reproduce it with a simple program.

The AvailableMemory function tells you the largest block you can allocate. With fragmented memory this is not a true indication of available memory.

As for every embedded design, memory is always an issue. I suggest you pre-allocate all memory(globally) that you might need. That way, you can control fragmentation. I have a previous program on my mbed that uses lots of malloc and I'm telling you, it's probably the buggiest piece of code I have written. Now, I recoded it to use global arrays that way, I can use them whenever I need without worrying too much that the next malloc is going to crash the program