Message |
|
The good news for everyone is that I am in the middle of implementing enough of a webserver to handle serving the react app, it is in progress and maybe a month or two away from production. But once it goes in, the tests so far on an STM32 board show that it is extremely lightweight and very fast, it does not block other tasks from running and should run on any board with a known network adapter and room to store the files.
I know this doesn't help people struggling with the current support right now, but this one needed me to take a step back before proceeding.
|
|
|
I increased the itemPadding in the theme file and that seems to help for a quick fix (it increases the padding all around, not just on the right side, but that's fine). I noticed that values which contain the number 1 seem to be pushed further to the right. Must be some quirk of the Adafruit font.
For the incorrect sizing, it may be worth creating a test sketch with these characters in and seeing if it is the font, or a problem in tcMenu. Although we are just getting the text bounds direct from the library.
If you have a look at the menu padding object though, it can be configured either with equal values for each side, or a value for each side:
MenuPadding(int top_, int right_, int bottom_, int left_) {
top = top_;
bottom = bottom_;
right = right_;
left = left_;
}
This should allow you to set each side separately.
For reference I've attached a photo showing this alignment quirk as well as the 0 value items showing blank (Minimum and Maximum Position items are both Large Number items.)
Yep, wrong way around
I'll take a look at these two later, and raise an issue if needed against TcMenuLib.
|
|
|
We have a board that is constantly setup for touch pin control, with a TFT display. I will try it later on.
Looking at the designer emf file you attached, it appears that all the touch sensors are on the same touch pin - 3. Maybe that is just the version you've copied here. Although I don't think that would cause a freeze.
I don't know if Arduino IDE 2.0 supports builds flags, but if it does, could you enable serial debugging by adding this build flag -DIO_LOGGING_DEBUG=1
If not in the IoAbstraction library open the file IoLogging.h and follow the instructions in there to enable logging.
Once that is enabled, please open the serial port, reset the board, and then send me the contents of the run. If you don't want to post that publicly, feel free to send in a private message.
Another thing to do, is to look at the Esp32 SimHub example sketch, as that uses touch pins.
|
|
|
|
|
|
Yes, RAM scroll choices are a bit tricky, I'll add an issue to autogenerate the variable in the sketch/main unless it is prepended with an @ symbol, in which case it assumes you will define it somewhere else.
https://github.com/davetcc/tcMenu/issues/216
Should be quite simple and go into the next release.
|
|
|
|
|
|
Seems like a very interesting project BTW. Always happy to help other open source projects.
Maybe the thing here is that I've baked something pretty custom into an example, that requires advanced features of the library that depend on specific boards to be enabled. Perhaps the example shouldn't use the BSP EEPROM to make it easier to get started.
Any feedback you have on how we could better handle that BSP support from a user perspective would also very welcome.
|
|
|
|
|
|
I think I have it, you have two on your class path
c:/users/g/appdata/local/arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2-patch3/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: C:\Users\G\AppData\Local\Temp\arduino-sketch-308E1AD3B25F93D54ED7638502BBDC66\sketch\src\ESP32TouchKeysAbstraction.cpp.o: in function `ESP32TouchKeysAbstraction::runLoop()':
C:\Users\G\Documents\Arduino\TCMENU5\src/ESP32TouchKeysAbstraction.cpp:12: multiple definition of `ESP32TouchKeysAbstraction::runLoop()'; C:\Users\G\AppData\Local\Temp\arduino-sketch-308E1AD3B25F93D54ED7638502BBDC66\sketch\ESP32TouchKeysAbstraction.cpp.o:C:\Users\G\Documents\Arduino\TCMENU5/ESP32TouchKeysAbstraction.cpp:12: first defined here
Worth checking if you have at some point after creating the project ticked the save to source directory setting, and therefore code generator started saving there. It should really give out a warning if that setting is changed after the project is generated at least once.
|
|
|
As a bit more detail, not everyone would want to use the battery-backed ram segment as EEPROM, and I don't think that all boards supported by Stm32Duino even have that available to them. As a result of this, I added that extra define to prevent it from attempting to bring in the BSP headers on boards that may not support that feature, or have slightly different capabilities. It is always a balance in these cases between supporting as many features as possible, and it not breaking for other users.
If you don't plan on using the BSP ROM you could just change it for another ROM storage option in the code generator dialog. For example No EEPROM or I2C EEPROM.
|
|
|
I've taken a look now, and there's a protection statement around the class because it requires BSP headers to be available for the board.
I question if the protection define is really required, as it may be causing more harm than good, especially if you're using Arduino IDE as you can't add a define at compile time.
If you take a look at
https://github.com/davetcc/IoAbstraction/blob/master/src/mbed/HalStm32EepromAbstraction.h#L16
and
https://github.com/davetcc/IoAbstraction/blob/master/src/mbed/HalStm32EepromAbstraction.cpp#L6
the error is because the code is not being included due to the define. The problem is that without the define, the code would attempt to compile whenever we detected Stm32Duino (or a suitable mbed board) and the BSP header needed by not be there. However, needing the define means that user hit this error unless the define is added.
For now, you can either add the compiler flag, or if you're using the standard IDE, just above the check in the header file, add
#define IOA_ENABLE_STM32_HAL_EXTRAS
This needs a bit more thought, it's trival for platformIO and mbed users, as they can easily add an extra build flag, but for Arduino IDE it is more difficult.
|
|
|
I'll need to look into this in more detail later today, I just tried compiling the regular touch pin example and it worked, so there must be a little more to it.
|
|
|
If you have a look in board manager, could you tell me what version of the ESP32 platform you've got installed, I'll try and recompile our touch sample with the same version?
Thanks,
Dave.
|
|
|
To get the currently active item you can use:
MenuItem* myItem = menuMgr.findCurrentActive();
There is no direct way to be informed of every change in terms of a new item becoming active. But what you could do is to take over the control of the primary encoder yourself (instead of using the plugin-provided primary encoder support), in that case, you would set the input plugin to no input required and set up everything manually referring to the guide below. Make sure the primary encoder is encoder 0. You could even look in the projectName_menu.cpp file to see what is put there by the code generator.
http://thecoderscorner.com/products/arduino-libraries/tc-menu/menumanager-and-iteration/#controlling-the-menu-items-manually
With that, you could change the precision whenever there is a new active item. Maybe it is that simple, there could well be a lot of edge cases that I can't think of, but I think you'd need to try it yourself.
|
|
|
|
|
|