Message |
|
Please can you confirm if you declared the u8g2 variable in your INO sketch file. The menu library only exports the definition.
Please take a look at the sketch in the esp8266 example shipped with TcMenu. You’ll see that this both creates the global variable and initialises the display.
With both u8g2 and AdaGfx there’s just too many combinations for us to initialise it on your behalf. Instead the library assumes the display is initialised before setupMenu is called in the sketch.
|
|
|
I think I found the issue behind the menu name not updating. It should be fixed in 1.3.2.
|
|
|
When using the SSD1306 library, the begin() call to initialise it needs to be specifically set for the type of display. Please see the examples that are packaged with the SSD1306 library for the display size you're using. You'll see there's a different example for each screen size.
|
|
|
Copied from email:
When I try to use the library with a 32 row SSD1306 screen the display works, but is blank with a 64 line display.
|
|
|
Please Revert to 1.3 for now until I can get hold of an ESP32 board to test with. Just downgrade the UI and then manually copy the libraries from 1.3 back over using the standalone zip that’s in the 1.3 release. This will keep you going for now. Sorry it’s not better news.
|
|
|
Ok, there’s no exceptions in that log. I’ll have to try and create some larger structures of about 150 items and see if I can recreate.
Could you also send me the Arduino compiler output where it fails for ESP32. I don’t have an ESP32 board to hand at the moment to test it with. Given they seem to be less than £5 I’ll get one from somewhere and make sure it works along with ESP8266.
|
|
|
The logs should be in your home directory. Normally that’s just /Users/YourUserName on Windows.
Within there you should see a directory called .tcMenu and it will contain a series of log files. Just pick up the most recent after you’ve recreated the problem.
The conflict between the designer and controller should be fixed in 1.3.1 that I’ve just released today. I found it myself earlier. It was caused by both installers using the same UUID. Just uninstall both before installing 1.3.1 and all should be good.
|
|
|
1.3.1 now has the ability to set the depth required - defaulting to 4.
|
|
|
The EEPROM is now wrapped in 1.3.1. See the ESP8266 example that is now packaged in the examples.
|
|
|
Just to let you know 1.3.1 has just been released for Windows (MacOS later this week).
There is a new example for ESP8266 that is setup for an OLED display. This shows usage of the ESP8266 EEPROM and WiFi.
The two click problem is fixed as well in this new version.
|
|
|
Please could you look in .tcmenu under your home directory for logs
~/.tcMenu
and send me the log file for one such run. I cannot recreate this locally after a bit of trying, and I'm thinking there's a strange exception or similar.
If you don't want to publicly post the log, feel free to PM me.
Many thanks,
Dave.
|
|
|
I had TcMenu all ready for release yesterday in the afternoon, including most of the fixes that we’d discussed, but at the last moment I found a showstopper bug in it with memory corruption.
Already tracked it down to one function, but I’m a bit time limited this week with work at one of my clients. So I’d say best case later in the week.
One of the big changes that Should be almost silent to you, is that ESP boards are now fully supported and have their own platform in the creator. There is a full example for the esp8266 including the first pass at WiFi remote control.
|
|
|
Scheduled tasks are supported by the underlying IoAbstraction, which underpins TcMenu. Supports both one shot and repeat triggering. In fact, it's how tcmenu does the button management, rendering and serial / ethernet remote.
Up to a few millis can be scheduled at the microsecond level.
Up to about a minute can be scheduled at millisecond level.
Up to about an hour can be scheduled at the second level.
Take a look at the taskManager sketch in the IoAbstraction library, it shows you how to create and use tasks. Should be easy to modify menu from those tasks. However, bear in mind that the accuracy of the scheduling depends on having no long running tasks.
|
|
|
To be honest, you're one of the early adopters and the docs are not completely finished yet, so it's fine to ask questions / find that functionality is still missing.
This is a bug that I've not noticed. The key is actually not repeating, but as I'd not mapped long press to anything, it came through the same channel. This is such a small fix and I'll fix in 1.3.1.
However, I see what you mean now. Yes, there is something close to what you want, there is an ActionMenuItem type. This just fires a callback on selection and nothing more. The designer UI adds these.
Once you get 1.3.1, nothing should trigger twice no matter how long you hold down the button.
|
|
|
So in version 1.3.1 there will be a configurable limit of the number levels supported in the menu structure. This is because many places use a non-recursive way of handling menu items.
The default setup would allow up to 4 levels away from root. For example:
Settings
+--- Sub Settings I
+--Sub Sub Settings
+-- Sub Sub Sub
+--- Sub Sub Sub Sub
It will be easily re-defined by opening file
MenuIterator.h
and changing the value
MAX_MENU_DEPTH
to a new value (obviously at the expense of a little memory).
|
|
|