Hello.

I was using tcMenu 1.7.1 (tcMenu Designer 2.0.beta) and all was working.

Now, I have updated PlatformIO library versions to tcMenu 2.2.3 (tcMenu Designer 2.2.3) and the project compiles right, but the OLED display is blank. What am I doing wrong? The designer project is very simple: Only a display (U8G2_SSD1306_128X64_NONAME_F_HW_I2C) and a theme (some pictures on attachments). The .emf is also attached.

I can confirm that the code is working because some printf are seen on the USB serial port console.

Any hint will be welcome. Thanks.

Have you tried writing to the screen directly after setupMenu() has been called?

Maybe something along the line of clearing the display and then printing something anywhere on the display and waiting for a few seconds. Dont forget to flush the buffer after printing something though!

Does this work?

Also, is there a Wire.begin in the sketch somewhere?

Also, is there a Wire.begin in the sketch somewhere?

No, neither in the old project nor this one there is a Wire.begin()
There is and three has been before gfx.begin()

Maybe something along the line of clearing the display and then printing something anywhere on the display and waiting for a few seconds. Dont forget to flush the buffer after printing something though!

I have added to the generated code, in the PROJECTNAME_main.cpp this

void setup() {
    Serial.begin(115200);
    printf("\n\nCalling setupMenu()...");
    setupMenu();
    printf(" OK.\n");

}

void loop() {
    taskManager.runLoop();
    renderer.takeOverDisplay(fnTakeOver);

}


void CALLBACK_FUNCTION fnTakeOver(unsigned int encoderValue, RenderPressMode clicked) {
    if (encoderValue != 1)
        printf("encoder: %d\tclicked: %d\n", encoderValue, clicked);
    
    gfx.drawCircle(20, 20, 18, true);

    renderer.giveBackDisplay();
}

No circle is drawn, and if I touch the sensors you can see changes in encoderValue over the USB monitor (printf), so it demonstrates fnTakeOver is called periodically (I don't print nothing if encoder==1):

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[ . . .]

Calling setupMenu()... OK.
encoder: 2      clicked: 0
encoder: 0      clicked: 0

Sorry if I don't know exactly how to draw a circle. My programmer skills are very limited.

No, neither in the old project nor this one there is a Wire.begin()

If you use the low latency driver, you may need to call wire.begin() somewhere with the right parameters provided. If you don't want the low latency driver (as before), you can turn it off in the code generator options.

--

Let's take a step back, we want to work out if the display has been correctly initialised during the setup call.

Therefore, during setup we want to do something like:

... other setup stuff

// this call should initialise the display
setupMenu();

// so directly after it we want to draw something and wait a few seconds.
gfx.drawCircle(...);
gfx.sendBuffer();
delay(5000);

... other setup stuff

You can remove the code that is attached to the callback.

Dear Dave.

I've inserted in setupMenu() the call to Wire.begin() just before the call to gfx.begin().
That has resolved the problem.

What I don't understand is why Wire.begin was not necessary in the previous project and now it is.

Where is the option to disable the low latency driver in the tcMenu Designer, anyhow?

THANKS for your help !!!

Wire.begin() should be one of the first lines in your own setup method, before calling anything else

It’s needed with the low latency driver because it overrides the way that u8g2 wire writes work, meaning that there is a more frequent yield to tcMenu. This makes the menu feel much faster in use when using slower 100khz I2c. The option for it is in the code generator properties for the display. It is one of the checkboxes.

Agreed that this needs documentation around it ASAP and we now have no planned designer changes other than additional displays and plugins. This will give me time to sort out the documentation.

Any feedback around where documentation can be improved would be most welcome BTW.

We are even considering open sourcing the majority of the main website to allow people to submit PRs to the documentation

Thanks a lot Dave.
The problem here is that I hardly understand the way tcMenu is engineered, because object oriented programming is almost new for me. I trust tcMenuDesigner and the libraries, and then I add my code (C without ++).
For that reason, I don't feel comfortable suggesting documentation improvements.