Encoder - 40 detents, 20 pulses.

We'll make sure that the memory mode defaults to Uno for now. To make sure going forward it should make it easier for Uno / small boards. Then for advanced users who want the new capabilities on bigger hardware, they can enable it by switching to full.

EDIT - actually it already does set it to unoLcd by default.

I released tcmenu 2.1 library fully yesterday, there's a new example esp32Lcd that demonstrates an I2C LCD with a regular encoder on ESP32. We found a bug in the LCD core class that only affected 32-bit boards. Up until now we'd done most LCD menu testing on AVR.

You need to be careful using an LCD with ESP32, the LCD needs 5V to operate and the ESP32 is not 5V tolerant, although the ~3V outputs will be enough to drive the data lines but if any of those become outputs they hold the risk of becoming high and therefore exposing the ESP GPIO to 5V. I only test 32 bit boards with I2C arrangements, where I can pull the I2C bus with the 3V3 line and avoid any risk of overvoltage.

Hi Dave.

I'm finally getting around to trying the QUARTER_CYCLE with a strange Amazon encoder. I'm seeing some very strange behavior -- mostly [but not always] related to changing directions. If I go up and switch to down, I need to turn one detent twice [or more] in order for it to start moving.

I've also seen menu items presented out of order on the way back up through a menu.

I'd like to help troubleshoot -- is there a way to attach a video here or in a PM?

Steve

If it is fairly small then you could attach it here (PM or in thread) in a zip file.

Otherwise, probably best that you use the "? Help" button on the bottom right of the main site. https://www.thecoderscorner.com/. With that option it raises a ticket and you'll be able to attach larger items to the ticket within reason.

EDIT - I may need to get hold of a quarter turn encoder myself to see what happens when the direction is changed.

I've also seen menu items presented out of order on the way back up through a menu.

This concerns me more, as it suggests that there is a problem somewhere in the renderer that is triggered under certain conditions.

Hi Steve, I've taken a look at the code again, and I think there is a problem with the direction change for quarter turn units, the logic only attempts to deal with things happening in the same direction. I think that I will need to try and get hold of a quarter turn encoder to determine what's going wrong here.

The problem is that quarter turn encoders are actually quite hard to find, as nearly all are now half or full turn that can be used with the existing logic.

I cannot reproduce the rendering out of order on the displays I've tried so far, but if the encoder is unstable, it could be causing jittery behaviour. If you could produce the video that would be great, also at the same time if you also turn on serial debugging that would be even better. If you are using a build system you can turn on the logging using the following build flag:

-DIO_LOGGING_DEBUG=1

I've not seen any responses in a while, so for now I'll assume this thread is on hold.

However, just in case others are interested, I think I have managed to recreate the display out of order bug on one of the examples, it seems to be a race condition with dialogs being shown and hidden in a callback. I will fix this issue before 2.2 goes out, and that is not too far away as it's going through testing now.

Also, if anyone knows where I can get hold of a quarter-turn encoder without having to make up a large order at a distributor, please let me know.