For the reset feature I've added logic for it as it is trivial. If you wanted it now you could try the below. If it works when I test it, it will go into the next release.

In tcMenu library, BaseRenderers.h take a backup just in case and add the following method directly after method setResetIntervalTimeSeconds

/** 
     * Completely turn off the reset interval so there will never be a reset. 
     */
    void turnOffResetLogic() {
        resetValInTicks = MAX_TICKS;
    }

In terms of the IoAbstraction, try:

MultiIoAbstractionRef multiIo = multiIoExpander(expanders); //<--Conflicting with this line
IoAbstractionRef multiIoRef = multiIo;

Then for the IO reference just put in "multiIoRef" instead. That should work as a MultiIoAbstractionRef should be directly castable to IoAbstractionRef

Wow quite a long post, hopefully I've got everything here..

Question1:

If I'm honest I've never tried a multiIO with TcMenu, but a MultiIO reference should be compatible with a regular IO reference. IE MultiIoAbstractionRef should be compatible with IoAbstractionRef.So you would just declare your device in the sketch and reference it as usual. Does this not work in practice?

Question 2:

This is possible, in fact, you can take complete control of the input facilities yourself. This is how keyboard support and touch works. See the section on manually controlling input in: https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/menumanager-and-iteration/

Question 3:

It should only happen when the menu is touched to be honest, it is to reset the menu so that it is in a good state if another users comes to start using the system at some point later. Many use this to display a screen saver or splash screen. If the menu hasn't been touched, it shouldn't reset. If it does reset under non-touch conditions, there's a bug that needs to be fixed. Are you asking to be able to turn off this behaviour?

Bug report:

Thanks, I'm in the middle of a taskmanager and tcMenu patch release. I'll fix the plugin XML.

Many thanks for that, I’ve ordered one now. Looking forward to it arriving as I have a board set up ready!

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

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.

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.

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

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?

TaskManagerIO requires that all the functions that you call are either asynchronous or can frequently call taskManager.yieldForMicros(..) if they need to be long-running or block for any reason. Tasks (including everything that tcMenu does) need the run loop to constantly run. I recommend that you read through the TaskManagerIO documentation: https://github.com/davetcc/TaskManagerIO.

On ESP32 or mbed, if you cannot arrange for this then you could create an additional thread to do the long running task, as long as the library in question is thread-safe enough to support that.

To be honest, most Arduino libraries don't block and in most cases just integrate with the loop pattern easily.

BTW on the override title front, I did a commit for that yesterday that will be in the next release.

https://github.com/davetcc/tcMenuLib/issues/125

You can see the commit also changes the dynamicMenuItems example to use the new functions.

Please see the new topic raised to deal with various touch devices within IoAbstraction:

https://www.thecoderscorner.com/jforum/posts/list/0/160.page

Is the FT6236 device similar to FT6206? If so it may be that one will work for the other?

A new topic just for touch screen support.

https://www.thecoderscorner.com/jforum/posts/list/160.page

This is a catch-all item for the implementation of touch support in IoAbstraction. We think that to have at least relatively comprehensive support we'd need:

* Support for resistive screens - IE +-X, +-Y. DONE and in production.
* Support for BSP touch functions within mbed for STM32. DONE and in production.
* Support for ESP32 based touch pins using the IDF API. DONE and in production for tcMenu only (move back to IoAbstraction?).
* Support for the XPT2046 device. DONE and working locally.
* Document the method for implementing a custom touch device . This will allow others to easily write the code needed to integrate another touch driver. DONE, example generated in IoAbstraction for this.
* Support for the FT6206 / CST026 so we can support the Adafruit capacitive touch units. In progress.

XPT2046 and FT6206 integration is working locally. We've also documented how to create a driver. The only code needed is the interfacing with the touch device, the calibration, debouncing, and everything else is already handled.