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