Using C++ Vector as container for display buffer

[martinberlin]

Test using Vectors instead of static buffers. The benefit is that Vectors can be redimensioned post instantiation. That way Bluethooth/WiFi provisioning can take more RAM at the start.

// Old way
//uint8_t _buffer[PLOGIC014_BUFFER_SIZE];
// Vector test: 
    vector<uint8_t> _buffer;
    vector<uint8_t>::iterator buffer_it;
    

branch: test/vector Related to #42
Read https://github.com/martinberlin/cale-idf/wiki/CalEPD-news

[martinberlin]

With the display buffer stored in a vector, when size is > 65536, it just restarts after throwing this exception:

0x400d6b9b: __cxa_end_catch at /home/martin/esp/esp-idf/components/cxx/cxx_exception_stubs.cpp:13

Backtrace:0x400d1f2f:0x3ffb24b00x40085cf5:0x3ffb24d0 0x4008b88e:0x3ffb24f0 0x400d6b9b:0x3ffb2560 0x400daebc:0x3ffb2580 0x400d7b3a:0x3ffb25a0 0x400d7bc8:0x3ffb25e0 0x400d7c1e:0x3ffb2600 0x400d6cbb:0x3ffb2630 0x400eb2d4:0x3ffb2690 0x40088cc5:0x3ffb26b0 
0x400d1f2f: panic_abort at /home/martin/esp/esp-idf/components/esp_system/panic.c:354

My measurements before and after initializing the vector are:
Free RAM before buffer: 292468
Free RAM after buffer: 226932

Probably out of RAM, only doable initializing the buffer in SPI Ram, WROVER or similar ESP32.

[martinberlin]

This works but it was just a test. Don't think is the wisest idea to use Vectors for a display buffer.
Anyways, here is the branch: https://github.com/martinberlin/cale-idf/tree/test/vector

To summarize:

• Vector is an amazing container. It's as fast as an static array but provides much better functionality. For example in the PlasticLogic models that need to have a 0x10 command prefix, this is easily done with vector.insert(vector.begin(),0x10)
  With an array this is not an easy task without an expensive copy operation.

• It has the great ability that can be dynamically resized. So it does not take RAM at the beginning and can be initialized after WiFi provisioning where we need RAM for other things like BLE (Bluetooth low energy)

• The downside is that all this flexibility comes with a size cost (A uint8_t buffer[1000] has a smaller size than a vector with 1000 uint8_t elements) And that's the issue with big buffers. In that case is the best to use PSRAM and *pointers that instantiate the buffer directly in that external memory.