To be honest we only test with the SPI version on Arduino, with modern hardware and the TFT_eSPI library extremely high speeds can be obtained. On mbed we have an example that uses the STM32F4 LTDC frame buffer hardware (it acts as an ARM peripheral with DMA and memory mapping), the results as you would expect are exceptional, and the boards "STM32F429 DISC1" are pretty cheap with an inbuilt hardware debugger. We also test with Adafruit GFX as well, as a lot of users use that library.

Using FreeRTOS on a Mega 2560? That would seem quite a small board to use a multithreaded OS with, personally, I only use FreeRTOS on much larger boards (STM32F4, ESP32, RPI Pico). Something to bear in mind, some parts of Arduino are not thread-safe, using the Serial object on another thread I've not tried, you'd certainly not want to use it ever on any more than one thread, and there could well be assumptions about what thread it is running on. Especially on a MEGA 2560. I would just use a regular task manager task instead and use Serial.available() to check if anything is there, it does not block.

Something like

taskManager.scheduleFixedRate(10, [] {
    while(Serial.available()) {
        // read a byte from serial here and process..
    }
});

Even within TcMenu, the assumption is that the core rendering code always runs on the main thread. Task manager integrates pretty well with FreeRTOS, so run a task manager loop on the main thread, and then you can offload work using CircularBuffers to be done on other threads.

Thanks, I have the log and the error is quite clear in there, now, I've saved it locally in case you wanted to remove the attachment.

I think the exception is just because the Arduino directory in menu "Edit" -> "General Settings" is wrong and needs updating. It should probably reset if it doesn't exist at start up.

Most configuration storage on Windows is in the registry, the root key for all our software is "Computer\HKEY_CURRENT_USER\Software\JavaSoft\Prefs\com\thecoderscorner"

If you still have the log from the faulting run would you attatch it here please so I can take a look and try to protect against this. Logs are in ~/.tcmenu/logs

(I have already fixed a good deal of wrongly assigned pin numbers and loose or badly soldered wires in this wire-monster.)

Certainly know that feeling. An amplifier I built is a bit the same and needs a major rework of the digital side.

BTW, when I tried to allocate 100 pin numbers (here as EXP_PIN_ALLOC constant) for each expander, the sketch freezed and I was unable to even upload a new, fixed sketch. I had to try about 20 times before I somehow managed to start the upload just between the reboot and the freezing of the sketch. So, there is probably some limit on the amount of pin numbers on the multiIo, which bricks the whole controller? With EXP_PIN_ALLOC set to 20 it works.

On Arduino (except the mbed based Arduino boards) the pin type is 8 bits. So the total range is 0..255

Following is "switches.changeEncoderPrecision(0, maximumEncoderValue, 0, false, 1);" for each encoder.
(BTW, this was a cause of serious issues for some time: without the last two values (which should be defaults) it is actually the shorter/non-overloaded version of the method that gets called insted of the longer one and it has a completely different meaning - setting the default encoder (no. 0) to the first value as maxValue! This ambiguity is indeed very confusing!)

I'm considering making a breaking change here on the new feature to make sure that nobody can use the wrong overload, I'll need to take a look at what can be done, it was an unintended consequence of a new feature.

We’ve never really tried to generate a high resolution Color TFT graphic display onto an 8bit device but at least theoretically nothing should stop it from working. That display is probably the one we test with the most. What you describe doesn’t sound right. Could you take a photo of the screen with the faulty characters please and attach here. I’ll look into the other issues later. Please also could you zip up the empty project and attach that too so I can take a look at that too.

I have to admit that I have not got a test bed with more than two rotary encoders at once. But with those two encoders on a PCF8574 I2C device, I don't see any problems with crosstalk between them. In terms of encoder quality, I test with cheap encoders generally without seeing many problems.

So some point here that may help:

Rotary encoder support is very sensitive to latency on taskManager, do you have any long-running tasks, if so, this may be the cause of the problems, and you may need to see if there's a way to reduce the latency of those tasks. But overall the behaviour you're seeing does not sound like latency, it sounds like either a hardware or software problem.

I would start with one of the rotary encoder test sketches shipped with IoAbstratction, start with it configured to pick up one of the encoders, see if it works without problems, even when turning others. Then add one more and so on. Even though the library can work with many encoders, I think most have probably not gone past 2 or 3 encoders.

By default MAX_ROTARY_ENCODERS is set 4, I'm assuming you've set this to a larger value already.

Unfortunately, this is a bit outside of tested use cases, and therefore may need a bit of debugging on your side.

Thanks for taking the time to write it up, it's always really good to see how the libraries are used in the wild. Great project.

Simplest example to look at for this would probably be the simhub example packaged with the library.

Sorry busy week this week. In terms of the how.

You’d probably start a task manager task that watches for items being updated and sends to your endpoint. You can use the menu item remote change flags to determine that. Take a look at MenuItem.h in the library.

For incoming state changes you’d just change the value of the menu item. You can determine the item then apply the change. All the value setters have an optional silent flag that prevents the callback if needed.

I imagine it would be relatively [edit] trivial to integrate Tc menu with MQTT. There is a longer term plan to try and build plugins for third party IoT solutions that are supported out the box

But even without that there are people out there that have integrated libraries themselves. All the building blocks are there.

There's now no need for the above steps, 2.5.0 was released today, it has the plugin packaged with it.

Simple collections 1.2.2 was released recently, it adds support for both RPI pico cores.

TaskManager 1.3.4 was released recently, it adds support for both RPI pico cores.

TcMenu 2.5.0 was released recently:

Make sure when you're ready to upgrade both the designer UI and library are upgraded at the same time. Otherwise, stay on 2.4 until ready.

The main improvements are:

Now builds for any RPI Pico core, Due and Uno Wifi R2.
Initial values are supported on nearly all types now.
Fixes to the priority of rendering to ensure dialogs always take precedence.
Starting to put low-power support into the display logic.
Fixes to how active items are handled to ensure that only one item is active at once, and the right one initially.
Cursor support has been fixed up to ensure the font used is correct.
Improvement in example arrangement.

As usual, available from https://github.com/davetcc/tcMenu/releases

IoAbstraction 2.4.3 was released recently, it introduces:

Complete support to use an OO listener for encoder change notification.
Both PI Pico cores are now supported, Uno WiFi Rev 2