1

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.

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!

trincot
  • 317,000
  • 35
  • 244
  • 286
Geoffrey R.
  • 1,907
  • 1
  • 19
  • 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 08 '13 at 22:15
  • I will use heap in order to dynamically instantiate GUI widgets, manage collections, and so on. – Geoffrey R. Jan 09 '13 at 08: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 09 '13 at 08: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 09 '13 at 08: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 09 '13 at 08: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 09 '13 at 08:28
  • Further embedded reading: http://www.barrgroup.com/Embedded-Systems/How-To and http://www.ganssle.com/ – Martin Thompson Jan 09 '13 at 16:06

2 Answers2

5

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 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.

edgar.holleis
  • 4,803
  • 2
  • 23
  • 27
4

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, 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.

Martin Thompson
  • 16,395
  • 1
  • 38
  • 56
  • 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 09 '13 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 09 '13 at 16:05