Scribd
Upload
88 views3 pages

C - Double Buffering On lpc1788 - Stack Overflow

The document discusses issues with implementing double buffering on an embedded system with limited heap memory. It describes the author's attempts to dynamically allocate memory for a double buffer at runtime which failed due to the small default heap size. Suggested solutions include statically allocating the buffer, increasing the heap size, or using conditional compilation to optionally include the buffer based on a compile-time flag.

Uploaded by

ciuciu.denis.2023
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
88 views3 pages

C - Double Buffering On lpc1788 - Stack Overflow

The document discusses issues with implementing double buffering on an embedded system with limited heap memory. It describes the author's attempts to dynamically allocate memory for a double buffer at runtime which failed due to the small default heap size. Suggested solutions include statically allocating the buffer, increasing the heap size, or using conditional compilation to optionally include the buffer based on a compile-time flag.

Uploaded by

ciuciu.denis.2023
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Double buffering on lpc1788

Asked 11 years, 3 months ago Modified 2 years, 4 months ago Viewed 699 times

I'm facing a great concern. I am currently involved in a sandwich course and I am learning on my own on
how to develop software on embedded system - as it happens, on the open1788 board.
1
I planned on implementing a double buffering feature because flickering can me seen on my LCD
screen. Shapes can be viewed while being drawn indeed!

With the double buffering, redrawing the entire screen goes fast enough. Maybe I should dig into
managing clipping so I would only have to only redraw parts of the screens that need to be? But that's
not the question.

So, I wrote a couple of functions in order to handle the double buffering option choice. If I don't want the
software to use the double buffering, so I won't allocate memory for it; otherwise I do.

The problem is that the default space allocated for the heap goes up to 1024 bytes. And my temporary
buffer has a length of 261120 bytes! (481 pixels wide per 272 pixels high, each one 16bpp).

As a consequence, malloc returned NULL.

The first solution I took is putting a static buffer, I mean:

static WORD s_double_buf[481*272];

But the obvious drawback is that it is still allocated even if you don't use the double buffering.

The second solution is editing the config file to make the heap bigger, replacing 1024 bytes per, for
example, 1048576 bytes (0x100000). I don't like this solution since I should focus on sparing memory
space.

Maybe I awfully miss embedded programming skills? What is the best solution according to that? How
could I make progress? I don't tell you about my messy ability to read and dig into datasheets.

I would really appreciate if someone could provide me with references for beginners, mostly
accomotaded to the board I am programming on.

Thanks in advance!

c embedded heap-memory double-buffering

Share Improve this question Follow edited Nov 19, 2021 at 19:08 asked Jan 8, 2013 at 14:15
trincot Geoffrey R.
332k 35 260 297 2,007 2 21 32

By what I've seen, embedded libraries usually limit heap so that it can go all the way up to stack (minus some fixed
value). If you don't allocate memory to heap (and don't use much stack), how and for what do you intend to use it?
– dbrank0 Jan 8, 2013 at 22:15
I will use heap in order to dynamically instantiate GUI widgets, manage collections, and so on. – Geoffrey R. Jan
9, 2013 at 8:19

I meant what's the use of free memory, if you can not use it for heap (and don't need that much stack). I.e. I'd just
change linker script, so I have minimal stack (just as much as required) and the rest would be used for heap.
– dbrank0 Jan 9, 2013 at 8:21

I am afraid I still don't understand your exact question. Do you mean free memory by memory outside of stack /
heap, like static & global variables that would be stored in .bss/.data section in windows/linux binary files? Cannot
tell you the equivalent in embedded environment. I must tell you that I did not think about it. So should I store my
double buffer in that memory region? – Geoffrey R. Jan 9, 2013 at 8:24

1 No, I think you should "edit the config file to make the heap bigger". Because how else will you use spare memory?
– dbrank0 Jan 9, 2013 at 8:26

With the stack I guess but it's quite limited and I would have to pass memory addresses through functions. I have
made the heap being bigger so it works fine, but I mostly wanted to know wether this is a sort of good practice or
not. – Geoffrey R. Jan 9, 2013 at 8:28

Further embedded reading: barrgroup.com/Embedded-Systems/How-To and ganssle.com – Martin Thompson Jan


9, 2013 at 16:06

2 Answers Sorted by: Highest score (default)

In the embedded space you would usually decide fundamental aspects like whether to use double-
buffering at compile-time, not at runtime. Therefore it is perfectly acceptable to use the preprocessor and
5 conditional compilation:

#ifdef WITH_DOUBLEBUFFERING

static WORD s_double_buf[481*272];


#define SCREEN s_double_buf

#else

#define SCREEN your_real_framebuffer

#endif

In the implementation of your GUI library you would then paint to SCREEN.

Share Improve this answer Follow answered Jan 9, 2013 at 14:53


edgar.holleis
4,901 2 24 27

With an embedded system, you usually want to allocate all your memory at startup. Which means you
already know you have enough for everything you want to do, which means it can't fail in operation,
4 which is usually a good thing, especially for an embedded system.

Statically allocate the memory - it's easy, and it looks like you have it to spare. If at a later date you find
that you run out of memory and can get away without the double buffering, then you can take it out just
as easily.

If you do use malloc , get it all done at startup, then you won't have to deal with recovering from running
out of memory during normal operation.

Share Improve this answer Follow


answered Jan 9, 2013 at 13:28
Martin Thompson
16.6k 1 38 57

Fair enough, so I guess I have to allocate sort of pools and then I shall not overflow them, Ain't I? – Geoffrey R.
Jan 9, 2013 at 16:01

If you have to have (unpredictable) runtime dynamic memory allocation, then you could use malloc , or your own
allocator. Either way you have to figure out what to do when you run out and have to return a NULL.
– Martin Thompson Jan 9, 2013 at 16:05

You might also like