SwipeContainer Pages use too much .bss memory

[VSimu.1]

Hello,

We have almost finished a product using touchgfx. We have 512k internal RAM on our stm32f767.

Based on profiling the linker file, 360k of our program .bss goes into internal RAM. Of that 360k .bss, a staggering 320k is only from SwipeContainer pages.

We recently tried to increase the number of pages of our SwipeContainer from 5 pages to 32 pages. But this would not fit. (Trying to compile, the application would not link). Now we are using 16 pages and we were able to calculate that every Swipe Container page uses about 20k .bss

Every single page of our 16 pages is the exact same custom container. It is copied 16 times 1-to-1. But with every extra page, there is 20k more internal RAM used.

Can you help me please? Is this normal? By decreasing the Wildcard buffer of one of the Text Areas inside of the custom container (where the TextArea is repeated about 16*7 = 112 times) from size 80 to 20, we were able to reduce the .bss size by about 50k! So please any hints on how to reduce this? Of course we can dynamically allocate everything, but we want to stay within the touchgfx philosophy and not use any dynamic memory for this big stuff.

Every 1 custom container (i.e. every Page of the SwipeContainer) has: 7 dynamic graph widgets, 35 Wildcard TextAreas of size up to 20, various buttons, various images from image assets, 21 buttons. But nothing crazy, it's not like a video game. It's pretty much all very static.

We noticed that our Windows Simulation .exe file also increased from 40kB to 50Bk, after increasing the number of pages from 5 to 16.

Any tips, hints, experience, etc would be very helpful and appreciated.

Regards

[MM..1]

Maybe better for your design is use swiping between screens and create many screens .

[VSimu.1]

This is not possible to change at this point.

And as far as the program. It is easier to have 1 Model with 1 View controlling 1 swipe container with 16 pages. Than to have 1 Model with 16 Views controlling 1 custom container which emulates the existing SwipeContainer

This is the whole point of having the SwipeContainer, at least to my understanding...

[MM..1]

Yes but screen objects is loaded to memory = swipe container load all elements...

When you need swipe you can use only two screens and change dynamic what is show for unlimited amount swiping...

Maybe ScrollList is better managed it generate only visible count custom containers, then when you use horizontal scroll ...

[VSimu.1]

You do make a valid point. That would solve our .bss problem.

But if we were to hypothetically change everything to be compliant with that, we would lose some of these functionalities that are currently enjoyed thanks to SwipeContainer:

• We have made the page indicators clickable. So we can click on each and change the page (as on Samsung smartphones)
• We have made the page indicators slidable. So you can slide across all pages (as on iPhone as of iOS 14)
• Elastic swipe is built in
• Small swipes in either direction make the DisplayDevice feel more "responsive" and "fluid". Like a smart phone. We would definitely lose this, and it would feel like an early 2010 sluggish embedded display. Or maybe that is the wrong description, but it would simply feel "less like a smart phone".

But in automobiles I have been inside, what you describe is kind of the solution. But it is not "like a smart phone". So I guess, if we want this "responsiveness", then we do ineed have to load everything into memory. And live with the increased .bss.

[MM..1]

Then you can try use SDRAM , bigger displays need it and sometimes i have 8M and only 2M used for display framebuffers

[VSimu.1]

This is not possible because the .bss must be in the internal RAM. We have a 16 MB SDRAM, but this does not help. Because we cannot put this .bss into SDRAM. The reason for this is because the .bss must be initialized before SDRAM. So thus this is not possible.

[MM..1]

You are not right, you can change init , ld , usw after init SDRAM

[VSimu.1]

I would gladly accept being proven wrong. But I do not follow what you mean by "change init, ld, usw". Do you have some external references that explain this, or could you please clarify further what you mean by this? I can try it out and then report back here what happened.

[MM..1]

Maybe this explain somethink for you SystemInit_ExtMemCtl(), DATA_IN_ExtSDRAM and SDRAM support · Issue #12770 · ARMmbed/mbed-os · GitHub

or search here for sbrk