Message |
|
To be honest, the functionality on the select button being held has never been properly defined so far, as I've not really needed it on my projects (amplifier, test apparatus).
I had a few thoughts, the first being that on select being held, the menu would go back one level.
I'd be glad to take feedback on options for that. If the functionality is simple, it could probably be incorporated into 1.3.1 or 1.3.2. Longer term, I think it would need to be configurable with a few ready-made options.
|
|
|
This is actually a bug that's is mainly already fixed in the next version, 1.3.1. I'd already fixed it in the display renderer while working on the extended ESP8266 support, but not got around to creating the issue for it yet. Just created now.
See https://github.com/davetcc/tcMenuLib/issues/15
Thanks,
Dave.
|
|
|
It should be possible. Probably a silent version of the setters that don’t perform the callback. I can see that being generally quite useful.
Please raise an issue against TcMenuLib for that. It’s a very small change and can probably go in the next version.
https://github.com/davetcc/tcMenuLib/issues
|
|
|
Agreed, I’ve been working on major improvements for ESP8266 support in the next release. I’m looking at ESP32 as well. I’m having a few problems with ESP8266 at the moment on master.
I’ll add the ESP eeprom support in a release soon.
See https://github.com/davetcc/IoAbstraction/issues/52
|
|
|
As you are not using an 8 bit board. Avr eeprom only works on boards with an avr processor such as Mega and Uno.
If you’re using a 32 bit board such as MKR then the best option is the i2c EEPROM example above. ESP support is still in progress at the moment but if you want me to wrap the inbuilt EPROM in flash library I can do so.
|
|
|
|
|
|
Hi there, thanks for posting the message.
We'll probably not write a custom driver for blynk just at the moment, as we are presently working on our own desktop and mobile apps, home automation integration, and integration with third-party IoT internet-based control systems.
The first iteration of this is already available (although currently very basic) as the tcMenu Controller desktop https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/tcmenu-remote-connection-arduino-desktop/ that can be installed alongside the designer application. You just either include either serial or network-based control into your design using the code generator. See the colorTftEthernet32 and remoteControlSerial examples. I've tested serial and network capabilities extensively using both 8 bit and 32 bit boards, further, it can be used with WIZNET (Ethenet2) and ENC28J60 (UipEthernet). I'm actually in the process of getting it working on ESP8266 boards now.
Further, there is a fully open source Java API that you can use yourself to control a tcMenu board. https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/tcmenu-java-api-to-arduino-remote-control/
However, to use this library with tcMenu should be simple enough, you'd just wire whatever notification you get on an item changing into the menu item. For example, lets say we got a notification from this library to method onNetworkChange() and we had a menu called menuMyBool and a global variable that has been updated called globalBoolValue:
// example of call back method
void onNetworkChange() {
// here we update the menu item, this is all that is needed.
menuMyBool.setBoolean(globalBoolValue);
}
|
|
|
Latest release is 1.4.3 which includes better testing and a new logging framework.
|
|
|
TcMenu 1.3 has been released. Huge improvements in support for Adafruit_GFX based displays, better remote capabilities including support for UipEthernet, ships with a basic remote control application and other minor improvements.
|
|
|
That’s great. It would still be good if you could send me the type of backpack that you had so I could take a look at why it wasn’t supported.
Don’t forget that if you adjust the display plugin file it will be replaced should you generate the code again. The easiest way out of this is to:
1. Rename the two display files
2. Set the display to no display in TcMenu designer.
Thanks
Dave.
|
|
|
Hi there,
We will try our best to get you up and running with TcMenu.
There are many forms of i2c display. Could you please tell me which i2c backpack that you are using with your display. What is important is the IO expander chip on the backpack and the pin configuration it uses.
LiquidCrystalIO can work with nearly all forms of i2c backpack but the configuration may need to be changed. However, should you have an unusual backpack I can show you how to make it work with your present library too with little effort.
If you could also send me the details of your backpack and the .emf file that would be in the same directory as your sketch. So I can see how it’s currently set up.
Many Thanks
Dave.
|
|
|
TcMenu 1.2 is now released. It has a new code generator, the first pass at acceleration, DFRobot support and improvements in task management amongst other fixes.
Read carefully though the release notes for this if you’re coming from 1.1.
|
|
|
I’ve finally got a sketch that recreates a bug in lcd rendering I’ve been trying to track down for a long time. The problem has been fixed.
As a result, the branch that work was taking place of has now been merged back into master.
In addition, an unexpected extra is that I've also got in the program memory optionality such that compilation now works on ESP boards. I have not run a menu on ESP yet, but it does compile.
|
|
|
TcMenu 1.2 is coming soon. It will be a significant departure from the old hardwired code generator. The new generator is far less language dependent and it will be possible to tailor code to environments much easier. I consider core code generation pretty much complete now.
In addition to this it uses IoAbstraction 1.4 so will also include the long awaited acceleration both on rotary encoders and also on switches.
Now all code plugins such as input, remote and display capabilities are loaded from plugins meaning it is much easier to provide new devices going forward.
There will be a small hit for existing users but upgrading should take less than a few minutes.
|
|
|
Also, In terms of interrupt polling. You’re already using interrupts for managing switches. So the only time it will poll is when a button is held down. Other than that it will wait for another interrupt.
The logic is
Wait for an interrupt
de-bounce
If pressed then Start timing loop
Check and fire any repeat keys
Keep in loop until no longer pressed.
Hope that is helpful
Dave
|
|
|