Message |
|
I've just made 2.1.4 of the plugins available as beta, to try them you can
1. Go to Edit -> General Settings
2. Select the Libraries tab.
3. Change the stream from Stable to BETA
4. Refresh the libraries using the refresh button
5. Click the update button to go from 2.1.3 to 2.1.4
You can easily go back to 2.1.3 by reversing the procedure and going back to Stable if there are any problems. We've tested the changes on ESP32, ESP8266 and Nano BLE.
|
|
|
I’ve now tested the HW_I2C and also the custom generator on a wide range of boards. It’s committed to master, and soon I’ll be making a patch - 2.1.4.
|
|
|
Quick update on this, I've now got the HW_I2C case working on ESP32 locally, mainly by a few small fixes in the plugin (and a very small change in the plugin C++ code too). It will take a day or two to finish it, as I'm trying to test more cases if I'm honest.
Testing - Quickstart plugin:
* Software on most boards already known to work
* Hardware (or using Wire basically) to be tested on ESP32, ESP8266, and BLE. This will be tested both with the wire-friendly yield on and off.
Testing - Custom U8G2 plugin:
* We'll test this on a couple of arrangements and make sure it's working.
|
|
|
Rather embarrassing to miss one of the basic cases really, and it's not worked for a long time, thanks for reporting it. I'm adding in the HW_I2C case now and I'll do a patch release of the plugins, I don't know how that one got missed!
The thing is that on ESP32 unless we actually define the SDA and SCL pins, it will call Wire.begin() - IE with no parameters. This will end badly because SDA and SCL will be on the wrong pins unless you're actually using the default pins (and not many do on ESP32 because they are mappable). A temporary workaround would be to use the NONAME_F_SW_I2C option until I can fix it. That's well tested on ESP8266 so should be OK on ESP32 as well.
As an aside, if you're interested in the internals - the way it works is that the Mac/Windows/Linux designer all use the same code base now, and they load in the XML plugins, and in particular this U8G2 one that we are using: https://github.com/davetcc/tcMenu/blob/master/xmlPlugins/core-display/u8g2SimpleBuilder.xml, notice in the functions section it has no match for .*HW_I2C, I'll get a fix out this week. I'll also make it so that it takes the SDA and SCL too. This allows in the future for others to extend the designer.
GitHub Issue: https://github.com/davetcc/tcMenu/issues/152
|
|
|
So before even trying to run anything, just looking at the plugin, I noticed a couple of things:
1. The simple case of HW_I2C had been missed completely, I'm adding it in now. After that, I'll test it in a new project and add the zip of it here.
2. the "simple" plugin was trying to handle all the complex cases! It was trying to handle the 2nd interface cases, and special named display cases, these have now been removed. Left are all the standard NONAME cases for every display in basic configurations. Anyone else (mainly advanced users) can use the full u8g2 plugin where they declare the variable themselves.
|
|
|
Agree this doesn’t sound right. It sounds like there’s a bad match pattern in the plug-in.
Can you let me know the board and I’ll try generating something similar from scratch myself on that hardware.
|
|
|
So I had a fairly rough time porting my program from an ATMega to the ESP32
ESP32 is a true RTOS, so has a memory manager etc, it is far less forgiving of any memory access violations. We test tcMenu on ESP32 heavily because it's one of our main development boards. We know that the core works well on ESP32.
I'm not sure what version of tcMenu / IoAbstraction you are using, but it must be quite old, as even going back to 1.7 does not seem to line up. I would recommend upgrading, there are fixes for ESP32 on the latest versions of all the libraries. That would be :
* TaskManagerIO
* LiquidCrystalIO
* IoAbstraction
* and tcMenu
I'm not sure if this is enough to give you a direction to point me. I'm not currently using any of the Taskmanager/IoAbstraction interrupts in my software.
The crash is a load of an invalid memory location in the rotary encoder interrupt.
I recommend that you create a branch, remove as much code as possible from the sketch and first try the menu in isolation, comment out wifi and everything else. Check if you still see the crash. If you still see it, I'll try and debug that version with a hardware debugger.
Otherwise, keep bringing code back in until the board crashes again, and at that point, it will be evident what's wrong and we can try and help there, to see if there's an incompatibility with something that you are using.
|
|
|
We stand ready to answer any usability questions around themes in the designer UI, don't be afraid to ask!
|
|
|
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.
|
|
|
TcMenu 2.1.3 plugins and library are now the main stable branch as of now. We've tested it as best that we can but we cannot ever capture everything. Please try 2.1.3 and give us any feedback here, if you run into problems it's quite easy to revert to 1.7.
You can stay on 1.7 quite easily, there's another top-level thread showing how to do this.
Why did it jump to 2.1.3 instead of 2.0? Because we did at least 10 internal builds, tested and better tested them, fixed anything that we could, and tried again.
|
|
|
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've got it functioning using the "Uno" (memory conserving) LCD feature. Selecting the "Full" library results in line 0 showing full blocks in each character position, with line 1 entirely blank.
I imagine the board is running out of memory, to be honest, and the sketch crashing. You can't even enable serial to debug the menu on an Uno, as you risk overflowing the available memory.
We really don't recommend full mode on Uno because it needs a bit more RAM and FLASH. It's designed for MEGA2560 and upwards basically.
|
|
|
I'm assuming you're expecting SCL on GPIO22, SDA on 21?
You have to call begin yourself providing the right pins before calling setupMenu(). Take a look at the ESP32 code below, begin takes two parameters that can be defaulted if you use the hardware mapped pins.
We do test ESP32 with an LCD for our LiquidCrystalIO library, but we've never really built a menu with one as it doesn't seem that common. However, I'll build one today and ensure everything is good.
https://github.com/espressif/arduino-esp32/blob/a1d8b959b05e3fb1391883ce6f9f2ed87af7da0f/libraries/Wire/src/Wire.h#L74
- slight edit to include url
|
|
|
Thanks for letting us know about it too, so we can fix it.
|
|
|
Ah, looks like there's an oversight for ESP boards in the liquid crystal renderer, not many use LCDs on ESP boards.
If you open LiquidCrystalRenderer.cpp and change line 119 to look as follows:
buffer[min(uint8_t(areaSize.x + 1), bufferSize)] = 0;
I think that should fix it. I'll include this patch in the 2.1.3 release, which will be tomorrow at this point. It will also include quarter-turn encoders. In fact I'll create a simple menu with LCD on my ESP32 board with my I2C LCD display. Normally we test ESP boards with OLEDs and TFTs.
|
|
|