Message |
|
So it turns out that debug I added ... that shows the values on the pins... was extremely helpful.
Best I can tell, something randomly happens which causes all of the pins to return different values. I was hovering in the 600s with no touch, then it would bounce to 1600s with no touch. It's not an electrical issue -- I've replicated it with nothing connected. I observed the numbers briefly with a small piece of standalone test code and ran with it, unaware there was more of a range than observed.
This is my current theory. I'll play around and overthink and see if I can come up with something else..
Thank you for everything you do!
Steve
uint8_t ESP32TouchKeysAbstraction::readValue(pinid_t pin) {
if(!allOk) return 0;
ensureInterruptRegistered();
uint16_t val;
touch_pad_read_filtered((touch_pad_t)pin, &val);
+ serdebugF3("TouchKeysAbstraction::readValue: ", pin, val);
return val <= pinThreshold;
}
|
|
|
Ok, this is interesting. It seems, if I wait long enough (many minutes) ... the touchpad springs to life. Prior to that, it will sit there and say intCount = 0.... and then, wham. It comes to life and works reliably.
I've tested this on a few ESPs. They all act the same way.
in ESP32TouchKeysAbstraction::readValue, I added some debug...
22:43:50.562 -> 504129:TouchKeysAbstraction::readValue: 1546
22:43:50.562 -> 504153:TouchKeysAbstraction::readValue: 5
22:43:50.562 -> 504153:TouchKeysAbstraction::readValue: 5
22:43:50.562 -> 504153:TouchKeysAbstraction::readValue: 1362
22:43:50.562 -> 504153:TouchKeysAbstraction::readValue: 1546
22:43:50.595 -> 504177:TouchKeysAbstraction::readValue: 5
22:43:50.595 -> 504177:TouchKeysAbstraction::readValue: 5
22:43:50.595 -> 504177:TouchKeysAbstraction::readValue: 1363
22:43:50.595 -> 504177:TouchKeysAbstraction::readValue: 1557
22:43:50.633 -> 504201:TouchKeysAbstraction::readValue: 220
Any ideas why the pad would randomly spring to life?
|
|
|
Hi Dave.
I'm seeing this already enabled:
// When line below commented out - no logging, when un-commented - logging. You can also define this macro in your build system
#define IO_LOGGING_DEBUG
// END user adjustable section.
... but I've never seen any debug? I'm assuming it goes to serial by default? I'm doing a Serial.begin() in my code -- could that be interfering?
|
|
|
Hi Dave!
I've been struggling to find good quality binary encoders, and have settled in on the ESP32 as my primary platform for projects. Since there's touch support in both the hardware and tcMenu, I figured I'd give it a whirl.
I'm struggling. I've been through all of the permutations in Designer. Nothing works. No errors, but no sensing. I've tried both interrupt and loop. Nothing.
On a lark, I added this to my loop():
Serial.print(touchRead(4)); Serial.print(" ");
Serial.print(touchRead(13)); Serial.print(" ");
Serial.print(touchRead(32)); Serial.print(" ");
Serial.println();
... when that code is present, I see ~200 with no touch, < 100 with touch.... I also see random touches (this seems to be an ADC issue) ... and the tcMenu cursor comes to life (and sometimes moves on its own).
I've got sensors on GPIOs 4, 13, 32 and specified 9, 4, 0 in the Designer.
I've walked through the code and would like to see if I can enable a debug mode. I see lots of info getting passed over to "serdebugF2", but it doesn't appear to be enabled.
Can you point me in the right direction?
|
|
|
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
|
|
|
Hi Dave!
I have a situation where I need to lock the user out of the menu. Is there a way to unload/destroy the object so pushing OK on the encoder does nothing?
Thanks!
Steve
|
|
|
Hi Dave.
Your initial reply was the pointer in the right direction. Adding setFontPosBottom() to my display takeover put things back the way they should be. This is the default setting.
It appears interacting with tcMenu results in that setting getting changed.
Might want to consider adding that in some of your takeover examples, something in release notes, or storing and restoring that setting?
Thanks for pointing me the right way!!
Steve
|
|
|
I can confirm the issue persists when using the title feature in the theme, as well. Below were the settings I tested with.
|
|
|
Here's a zipfile for the demo.
Note I am not using the Title features in Mono/OLED and have "Border Size of Title", "Spacing between title and first item" set to 0, and "No Title" selected. I haven't experimented with the title feature to determine if using the title makes the issue different. I'll try and do that today.
TCMenu version is 2.13, Mac. Library stream is BETA, and is current.
|
|
|
Image "1" is the initial screen at power-on.
I pressed the encoder, which displayed the menu (Image "2").
When the menu times out, the same code that displayed Image 1 looks like this (Image "3").
Note the images seem to display in the opposite order.... go bottom up. =)
|
|
|
Hi Dave.
I've got a strange one here. I boiled all of it down to some sample code, but I'll explain it and add some pictures before attaching the ZIP for a demo.
I'm doing an initial display grab to prevent the menu from appearing at boot. This screen would normally have status information, and a press of the encoder brings up the menu. After the timeout, the status screen should re-appear.
This is working, with an exception. The position of text on the screen is different after the first time the menu displays. Things appear to be moving "up".
To demonstrate, I'm displaying a series of underscores and dashes, right at the bottom of the display. The underscores are purposefully cut off, in order to demonstrate the movement.
-_-_-_-_ ...
At startup, you only see the dashes:
- - - - - ...
This is the expected behavior. After clicking the encoder and getting the menu, the screen will shift up some pixels, and you'll see the whole string:
-_-_-_-_
Is this a bug? Am I doing something wrong?
#include "tc-cursor_menu.h"
#include <Wire.h>
#include <Adafruit_GFX.h>
#define MENU_TIMEOUT 5
U8G2_SH1106_128X64_NONAME_F_HW_I2C gfx(U8G2_R0, U8X8_PIN_NONE, U8X8_PIN_NONE, U8X8_PIN_NONE);
void welcome(unsigned int encoderValue, RenderPressMode clicked) {
if (clicked) {
renderer.giveBackDisplay();
}
gfx.clearBuffer();
gfx.setCursor(5, 65);
gfx.print("_-_-_-_-_-_-_-_-_-_-_-");
gfx.sendBuffer();
}
void setup() {
Wire.begin();
gfx.begin();
setupMenu();
renderer.setResetCallback(onMenuBeingReset);
renderer.setResetIntervalTimeSeconds(MENU_TIMEOUT);
renderer.takeOverDisplay(welcome);
}
void onMenuBeingReset() {
renderer.takeOverDisplay(welcome);
}
void loop(void) {
taskManager.runLoop();
}
|
|
|
Ah ha! That was it. Thank you, Dave!!!
I still think there's something awry with the Simple stuff, I just don't know what or where.
=)
|
|
|
I'm using the Advanced version. I'm pretty sure I've been at this point, ran into a problem and then tried the Simple...
I've got the global:
U8G2_SH1106_128X64_NONAME_F_HW_I2C gfx(U8G2_R0, U8X8_PIN_NONE, U8X8_PIN_NONE, U8X8_PIN_NONE);
And in setup():
Wire.begin();
gfx.begin();
setupMenu();
renderer.setResetCallback(onMenuBeingReset);
renderer.setResetIntervalTimeSeconds(MENU_TIMEOUT);
renderer.takeOverDisplay(welcome);
The welcome() function worked on all other display types. For some reason, I'm getting nothing on the LCD screen until I press the OK button on the encoder, then I'm presented with a menu. After the timeout, the display goes blank again.
I've confirmed the takeover function is getting invoked via serial logging.
The welcome() function is pretty simple -- stuff like this.
gfx.clearDisplay();
display_struct.updateTop = false;
display_struct.updateBottom = false;
gfx.setCursor(0, 0);
gfx.print("Welcome");
gfx.display();
delay(5000);
gfx.clearDisplay();
I don't think this is a bug. I'm just on the struggle bus with this particular display..
|
|
|
So frustrating!
The toaster example compiles and works perfectly with the display. It's got 5/4 listed for the pins in Designer, and Software I2C. Calls Wire.begin() with no options.
Interestingly, my display appears to be on 26/29 (SDA to D22, SDA to D21). Replacing that in Designer and/or Wire.begin() ... still no display with your test code.
What could I possibly be doing wrong?
|
|
|
Hi Dave. Yeah, as soon as I made that post .... I realized there were two sets of generated files. Cleaned it up and unchecked the "src" box.
I'm presently compiling with Wire.begin() and the pins specified in the UMF file. I'll try it your way.
|
|
|