Object oriented programming crashes my M5StickC Plus about lovyangfx HOT 8 CLOSED

@m1cr0lab
There is a fatal bug, sorry about that.
Try the one on the "develop" branch.
It was probably fixed in the commit on December 19 last year.

The cause is that the structure of the LovyanGFX type is different in each compilation unit.
In the main.cpp, LovyanGFX file system support is enabled by the presence of the M5StickCPlus library, but GraphicsEngine.cpp no longer includes file system support.
This problem was fixed late last year, but we have not yet released it.

from lovyangfx.

I have a new lead...

If I rewrite the code this way, it works:

// main.cpp

#include <M5StickCPlus.h>
#include <LovyanGFX.h>
#include "GraphicsEngine.h"

LGFX lcd;

GraphicsEngine ge;

void setup() {
    M5.begin(false, true, false);
    lcd.init();
    lcd.setColorDepth(16);
}

void loop() {
    M5.update();
    ge.draw(lcd);
}

// lib/GraphicsEngine/GraphicsEngine.h

#pragma once

#include <LovyanGFX.h>

class GraphicsEngine {

    public:

        void draw(LGFX &lcd);

};

// lib/GraphicsEngine/GraphicsEngine.cpp

#include "GraphicsEngine.h"

void GraphicsEngine::draw(LGFX &lcd) {

    LGFX_Sprite fb(&lcd);
    fb.createSprite(135, 240);
    fb.clear(0xfe40);
    fb.pushSprite(0, 0);
    fb.deleteSprite();

}

But why does the stick crash when I create the framebuffer as a global variable?

from lovyangfx.

@m1cr0lab
I have created a new release ver 0.3.5 which fixes this issue.
I hope you will try it when you have time and see if it solves issue.
thank you !

from lovyangfx.

Thank you very much @lovyan03, everything is working fine now.

from lovyangfx.

I've had a similar problem with Arduino IDE, and found out all my .cpp files are ignored at compilation unless they are included as libraries :-(

A quick test to see if this is the problem you're having is to move the contents of GraphicsEngine.cpp into GraphicsEngine.h and have the problem go away.

If so, maybe adding lib_ldf_mode = deep in your platformio.ini (and playing with the different values) may help

from lovyangfx.

Thanks for the idea @tobozo ... but :

• actually, if I move the content of the .cppfile to the .h file it works,
• but when I separate the code and specify the lib_ldf_mode = deep it doesn't help
  (the chain+ and deep+ options don't help, of course)

In fact, the compilation goes well. It's at runtime that it goes wrong.

Yet I've always done it this way in my projects on ESP32. I've never had this problem before. And I remember that this way of structuring the code worked well with an older version of LovyanGFX (at least the 0.2.4 version anyway).

And now that I've switched to 0.3.4, the problem occurs! It's really curious. Does it come from the way the library is structured? The deep option however analyzes all dependencies recursively. Rhaaa... it's frustrating not to understand.

Anyway, thank you very much for answering me so quickly.
Maybe @lovyan03 will have an idea?

from lovyangfx.

LGFX can handle multiple displays, and the global instance has no config before the init(), so you were probably accessing a configless instance when the crash occured.

noob idea: the GraphicsEngine could probably be instanciated after lcd.init() and also get the lcd object injected in order to avoid the global access.

GraphicsEngine *ge = nullptr;

void setup()
{
   lcd.init();
   ge = new GraphicsEngine( &lcd );
}

also I'm used to pointers when it comes to passing sprites as arguments

from lovyangfx.

Indeed, by including in priority the M5StickCPlus library in the .cpp file, the problem disappears :

// lib/GraphicsEngine/GraphicsEngine.cpp

#include <M5StickCPlus.h>
#include "GraphicsEngine.h"

void GraphicsEngine::draw(LGFX_Sprite &fb) {

    fb.clear(0xfe40);
    fb.pushSprite(0, 0);

}

@lovyan03 @tobozo Thank you both for your precious help and diligence.
And above all thank you for the fantastic work you share with us with this absolutely great library.

from lovyangfx.