I2C rotary encoder implemation

[evanderkuy]

Just started working with tcMenu in a ESP32 S3/SSH1107 128x128 project (and I like it very much). I run into an issue for my input device. I am using a I2C based rotary encoder by Duppa. Using their library I am using callbacks on events like increment, decrement, button pushed etc. Meaning I would like to interact with the menu from code only from within my callback functions for the encoder.

Is this possible and how should I do this?

Thx
Etienne

[evanderkuy]

I am trying to workout a customised input tcMenu plugins for the issue.

[davetcc]

The easiest way to proceed is to use the TcMenu provided plugin for rotary encoder, it supports a vast range of I2C devices.

However, if you have decided against using the built in plugin, you'll need to wire it up yourself. If this is only for yourself and not others too, do not to write a plugin. Just set input to the no input plugin, and then configure the input yourself instead.

Over time I've found that the best way to proceed is to implement the RotaryEncoder interface, and then set up that rotary encoder in the same way that the input plugin does. See IoAbstraction's SwitchInput.h file.

I recommend you generate a menu with the regular rotary encoder plugin and see what it generates first. But at a minimum you'll need to:

• Change your tcMenu project to use the "no input" plugin
• Create an implementation of RotaryEncoder (you could use one of the base classes if helpful).
• Register that encoder with "switches" as encoder 0.
• Lastly wire through the events, for this see: https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/menumanager-and-iteration/#controlling-the-menu-items-manually

[evanderkuy]

Good morning Dave,

Thank you so much for your fast response. I do now indeed use "no input" and just use :
on my I2C encoder increment/decrement callback (it gives the value of the counter): menuMgr.valuechanged()
on the I2C encoder button release callback : menuMgr.onMenuSelect(false)

That is working, except when my encoder increases over the number of menu ID's in place. I needed to have a look at that.

But you are right, let me try a regular encoder one more time, as I always had issues with them (no matter what library I used), maybe your logic is reliable ;-). Now that I have tcMenu running together with u8g2 I can test this properly.

That events page for the menu's I did not came across before, that is a great page.

Keep you posted, you gave me a lot of information, so I am sure I can work it out. Many thanks! When it is working I will make a nice donation.

[evanderkuy]

Ok, the normal rotary encoder works fine. Now, I only need to have a faster response on the display when navigating through the menu. The pointer is lagging with my rotation (and misses some when I dial "too" fast. I have tried to increase the SPI rate right after gfx.begin(); to gfx.setBusClock(10000000); without any result, also tried to change hw accelation to none (HWACCEL_NONE) in tcmenu.cpp as somebody suggested, but still no change.

What can I do to increase the speed?

I am using ESP32 S3 and a U8G2_SSD1327_WS_128X128_F_4W_SW_SPI display.

[davetcc]

I'm assuming you've set the updates per second in the display properties on the code generator. The encoder should send through updates fairly quickly, on faster displays I usually set the updates per second to 10 and use interrupt mode on the encoder.

[evanderkuy]

Yes, that is exactly what I use, screen updates = 10/s and "everything event driven, no polling". But the slow behavior is not acceptable for my application. I can't imagine this is the max we can do with the SPI and ESP32 S3? I think it is 1 or 2 toggles a second, scrolling to a list of say 10 items is not acceptable that it takes 5 seconds.

Any clues what other options are there to improve speed?

[evanderkuy]

Are LCD displays faster in general?

[davetcc]

The fastest display in terms of latency to write over SPI is an OLED, it's monochrome and can handle quite high SPI speeds.

Ref encoder, agreed, that does not sound right. The only way forward is to try the IoAbstraction rotary encoder examples first and see if the same latency is noticed there. TcMenu uses IoAbstraction for all input related plugins. Following that you could also try your other library mentioned earlier and then make a call on what to do.

[evanderkuy]

Hi Dave, After some hardware updates for my own board, I have picked up my “menu topic” again. I am struggling and wonder if you spend a couple of hours for consultancy in supporting me to get it to work? Using : Waveshare OLED 128x128 that is using SH1107 driver in SW SPI mode ESP32 S3 (on a Waveshare ESP32 S3 mini board) Adafruit SH110X library (G8U2 does not support SH1107 in SW SPI mode) On Windows Arduino IDE I have/had it running, but slow on the response like we discussed. Now I am fully over to Ubuntu and Platformio using JTAG pins (39,40,41 and 42) and ESP-PROG debugger/programmer. I started on a new project. I am able to compile and upload it. But on the serial port I see the device is rebooting every second. When I create a project for showing text with just the Adafruit library that works fine. Let me know what is possible to help me out and getting the response faster? Enjoy the weekend! Etienne From: Dave Cherry ***@***.***> Sent: Tuesday, April 16, 2024 10:25 AM To: davetcc/tcMenu ***@***.***> Cc: Etienne van der Kuy ***@***.***>; Author ***@***.***> Subject: Re: [davetcc/tcMenu] I2C rotary encoder implemation (Discussion #460) The fastest display in terms of latency to write over SPI is an OLED, it's monochrome and can handle quite high SPI speeds. Ref encoder, agreed, that does not sound right. The only way forward is to try the IoAbstraction rotary encoder examples first and see if the same latency is noticed there. TcMenu uses IoAbstraction for all input related plugins. Following that you could also try your other library mentioned earlier and then make a call on what to do. — Reply to this email directly, view it on GitHub<#460 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BGWUWGSQU3LUEURJEHJAMUTY5TN47AVCNFSM6AAAAABGFOO2HKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCMRXGEZTK>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[davetcc]

I'll need to read this through more carefully when I have more time and try to understand what is going wrong.