Reducing RAM Consumption

My current project is on a blue pill and I’m driving at RGBMatrix 128×32 pixels with double buffer, also I receive a paginated content of the video buffer from SPI in a DMA buffer which also uses double buffer since I need to do some processing from the DMA buffer before send to the VideoBuffer.

So at minimum I have 14344 bytes used before the code starts, the blue pill is 20K so I’m playing on the limits and don’t have much left, however I noticed than an empty program might take from 2 to 3Kb

What can I do to reduce the RAM usage? I noticed if I compile to upload with Serial the program is substantial smaller 2824 for STLink vs 1968 for Serial.

I see that the smaller program is when I compile to upload with Serial and then choose optimization Fastest(-O3) with LTO. “14256 bytes (69%)” which is weird since initial memory foot print shouldn’t be less than 14344, Serial is much slower to upload than STLink

Why Serial is smaller and is there is a way to reduce the initial RAM footprint for an empty sketch?

#define VIDEO_FRAME_SIZE 6144
#define VIDEO_BUFFER_SIZE VIDEO_FRAME_SIZE * 2

uint8 videoBuffer[VIDEO_BUFFER_SIZE];
uint8 dmaBuffer[1028*2];

void setup()
{
Serial.begin(115200);
while (!Serial) {}
Serial.println(videoBuffer[0]); // Forcing linker to include the buffer on RAM for demo
Serial.println(dmaBuffer[0]); // Forcing linker to include the buffer on RAM for demo
}

void loop() {}

You could save some RAM if you avoid Serial (USB).
So try either no serial at all or Serial1/2.

How do I disable the USB?

Remove from boards.txt for the respective board the compiler flag: “-DSERIAL_USB”.

@castortiu:

Sounds like you are painting yourself into a corner by selecting the blue pill. As stated, buffers consume the vast majority of SRAM, so my take on this is that you are using the wrong uC.

Ray

Maybe it’s better to test a full empty project!
void setup()
{
}

void loop() {}

I’m with Ray. There are ways to save a few hundred bytes here and there by removing parts of the core for peripherals you don’t use. But it’s still a 20KB mcu. Why not use an RCT6 mcu with 48KB?

The Stm32 is working as a slave driver of the master, the functionality basically is limited to drive the RGB and answer a couple questions as time from the RTC when the device boots. I haven’t hit the limit of RAM yet but I’m close and looking for alternatives before jump to different MCU, however I’m open to switch as well.

I’m fairly new…. what is a RTC6?
Also why when compiled to be uploaded with a STLink takes more than 1K more than when is compiled to be uploaded with Serial?

I have an order of a STM32F407VET6 on the way, however seems huge on capabilities for what I need, I’m trying to reach the capabilities on the device before throw more hardware to the problem..

if you modify the core, you can get rid of Serial USB, but you should also get rid of all the hardware serial buffers as well.

But ultimately this will only free less than 1k

Arduino is designed as a teaching tool, and is not optimised for speed or size or RAM usage, so if you want to push the MCU to its limits, then you should ditch using an Arduino core entirely, and use something like LibOpenCM3, or do what the bootloader code does, and access the hardware registers directly, with no framework at all

[castortiu – Tue Dec 05, 2017 5:08 pm] –
<…>
I have an order of a STM32F407VET6 on the way, however seems huge on capabilities for what I need, I’m trying to reach the capabilities on the device before throw more hardware to the problem..

As an old rule of thumb, the programmer should start to look for was to be more efficient at 80% of RAM utilization and should rearchitect or select more capable h/w at 90%.

Personally, I have never seen re-architecture out in the wild because in commercial development the boss will simply fire any programmer that suggest starting over with a new design after a significant portion of the coding phase has been expended. It is always “easier” to explain the need for new hardware resources.

No one here cares if you run at 99.9%, but I think it silly to build a software system that can not adapt to at least a small amount of enhancements or fixes.

Ray

A big lesson I learned, (at my own expense recently), was.

Never under-spec a prototype.

If there are 2 or more, pin compatible and software compatible, versions of the same device, get the better spec devices e.g. more ram or better speed etc etc for the prototype,
Otherwise you can end up with a batch of unless boards, or ones where you waste hours trying to optimise the code to work.

If you over-spec, it will cost 50% extra on 10 prototypes, but at least they will all work, and you can optimise later to see if you can get away with cheaper device(s) in the final product.