Message |
|
I'm at a bit of a loss as to where the error is coming from, even though we've normally compiled that example for ESP8266, there's nothing that should prevent it working with ESP32 (other than pin / device differences).
Have you tried regenerating the example, loading it into tcMenu Designer and then running the generate code option?
Everything looks good in terms of versions, on the code generator page, which display option does it show? I suspect something from 1.7 branch got into a 1.6 example somehow. I'll need to double check again tomorrow.
|
|
|
Please do not use these builds for everyday use, they are not regular builds of tcMenu, they are only for testing. Backup everything before testing with them!.
Please leave any feedback in this thread.
|
|
|
|
|
|
Is this the stock u8g2 example shipped with the library?
Please could you let me know the library version you have and the designer version too.
|
|
|
Thanks for the detailed response. I’ll try and setup a dual rotary encoder arrangement on a 32 bit arm board as soon as I can. I will find the most similar hardware to what you have.
|
|
|
The multiple encoder support was kindly contributed to the library some time ago, so I'm not that familiar with it as we've never really needed it in any of our projects. But it works and has been used by several projects that I'm aware of.
For the question, the answer is no, you should not need to use an expander in order to use more than one encoder, they should work perfectly with device pins. However, everyone I'm aware of who's used them has invariably used an expander. If you intend to use this with device pins, can you try it and feedback any errors here, also indicating which target device you are building for. If there are any problems, I'll build the circuit with the closest device I have on hand, and test it myself as it would be good to have it working for all. I'm assuming it's not AVR as they don't have enough interrupt capable pins for wiring up more than one encoder.
The only restriction should be that pinA of each encoder must be on an interrupt capable pin. I'll also add a task to clean up the documentation a bit around this.
I'd also suggest that you maybe search this forum and the IoAbstraction repo issues for multiple rotary encoders, because there's been a few discussions around this in the past.
|
|
|
If i use the "auto" button, i always get "2-2", for every entry in the table
Not all menu types can be saved to EEPROM, for example, SubMenuItem, ActionMenuItem and FloatMenuItem cannot save to EEPROM. Float menu item is only designed for readonly values, for editable values, use AnalogMenuItem as it always provides an exact value.
In the newer Windows Store version you cannot set an EEPROM value for those types. Could you tell us what was wrong when you tried the Windows 10 version?
|
|
|
Great news that you've got it working now.
In the ROM Layout window, the a - b are the start and size of the EEPROM space that the item would take.
Lets say that you generated a text menu item that was 10 characters long, and set the EEPROM address to 20. It would start at location 20 and take 10 bytes of EEPROM. The rom layout dialog is trying to show you this graphically, so you can see how the EEPROM storage is organised, if that makes sense.
These positions in EEPROM are used in the load() and save() functions of menu manager to read and write the current value. There's many different ways of using EEPROM, most are shown in the examples. If you are using an AVR based board (Uno, Mega2560 etc) then you can:
Add this include:
#include <EepromAbstraction.h>
Add this global variable in your sketch:
AvrEeprom eeprom;
Lastly, in setup after setupMenu is called:
menuMgr.load(eeprom);
Then at some point, (to start with maybe in the callback of an action item)
menuMgr.save(eeprom);
|
|
|
The example located in examples/analogDfRobot example should work out of the box with any regular dfRobot shield. It just reads analog in and renders it into the menu. Please load this example into your IDE and try to upload it. You shouldn't even need to run the code generator in tcMenuDesigner as it's pre-generated. If this does not work, please send me:
* a photo that shows the situation on the shield with the sketch running
* the output of the Arduino compiler and the version of tcMenu library that you are using
* the hardware that you are using and how it's wired up.
Also, note that if you are using the regular Arduino IDE that it does not refresh files, so if you generate a menu while it's open in Arduino IDE, it will not update. This is a limitation of Arduino IDE and not tcMenu.
Thanks,
Dave
|
|
|
As I said in the previous reply, you need to get code that is working with your display first.
I assume you have a 16x2 LCD display according to your first post. In that case, the first thing you have to determine is how that display is connected to the Arduino device. EG: Is it connected via I2C or is it connected directly to pins on the Arduino.
I'm assuming you are seeing boxes on the first line of the display, which would normally mean it is not configured properly. If you can't see anything at all, it is possible the contrast potentiometer is set wrongly.
---
Step 1: Does the display work when you use one of the LiquidCrystalIO or LiquidCrystal examples.
For example for I2C connection use this example and read the comments carefully on how to configure it: File > Examples > LiquidCrystalIO > HelloI2c
For example for DfRobot LCD shield: File > Examples > LiquidCrystalIO > HelloWorld
For any other pin configuration (you'll need to change the pins manually in the example): File > Examples > LiquidCrystalIO > Display
---
Step 2: To help you any further, you'll need to describe the exact set up here. EG what type of LCD are you using? How is it connected to the Arduino? The outcome of getting the LCD to work in step 1
Thanks
Dave
|
|
|
So i installed the Windows10 App, everything works fine, but i didn't found the way to generate code
On the Windows 10 version the generate button is on the tool bar, looks like a download symbol. But it only enables when you save the menu for the first time. We'll try the process ourselves again and maybe see if we could make it clearer. thanks for the feedback on this.
And now ? How can i start the menu on my LCD (16x2) ? What function musst i call
By default the menu should start immediately. You actually have to turn the menu off when you don't want it to display.
What I normally do for a new board, is just to get LiquidCrystalIO working with one of the examples first, there's an example for DfRobot and for I2C, you can customise it to your arrangements in a test sketch. Once that's working it's usually easy to get the rest working.
Hope that helps.
|
|
|
As of version 1.6 of IoAbstraction you no longer need to redefine these parameters. However, if you want to avoid reallocations you can allocate these yourself to specific values just as before.
* Task Manager will grow on 32-bit boards up to 256 tasks, and up to about 80 tasks on larger 8-bit boards. It uses a tranche system, so for example on a 32-bit board, it will start with 16 tasks then allocate another 16 when needed. Until it reaches the maximum number of tranches.
* Switches will reallocate keys as needed starting with reasonable defaults. It uses the lightweight-collection that is built into IoAbstraction, so as you exceed the number of switches it reallocates the backing array.
* Note that Rotary Encoders do not automatically reallocate, this is because most people don't need more than 4 rotary encoders. You still need to change this manually if you need more.
|
|
|
thanks for your awesome library. I'm already doing some cool things with it.
You're welcome, I'm always glad to hear how it is used.
Those two "menuSave" will then clash when compiling.
Have you tried setting the use fully qualified names option, in the app store version, it's on the ROOT menu, on the Java version it's on the Generator page.
This gives fully qualified variable names. EG: menuEthernetSave and menuWiFiSave
But noted, in the future I'll see if it's possible to actually provide manual names, in case that is not enough.
It would be good to be able to either generate the enum-values OR add a name which references an already existing array.
For enums, we are introducing a new type at the moment called ScrollChoiceMenuItem, that will compliment rather than replace the current support for more complex cases, with this you'll have far more flexibility on how to provide the values. It can change size and values at runtime. It will be able to read values from:
* A fixed array in memory
* EEPROM storage in a fixed array (optionally cached)
* Delegate Callback function that will be asked for a string equivalent for each value.
This will give far more flexibility for enumerations, and allow for pretty much every case.
|
|
|
Yes, actually, I've taken it a step further and am creating a ScrollMenuItem, this will be able to scroll through large lists of items that change at runtime. For example, the channels on a DAB radio or the tracks on a CD. It will have several choices:
1. The ability to fill it as you go, by providing a delegate callback that's just asked for the string value of each item index.
2. The ability to provide a number of values from EEPROM in a fixed array, again the size can change at runtime, and if less than 255bytes can be cached into RAM, as EEPROM is very slow to read.
3. The ability to provide a fixed array in RAM (similar to the EEPROM example but in RAM).
4. Stick with the existing enum item for smaller fixed arrays like now.
|
|
|
Thanks for updating with your findings.
If you are using the Java UI (for Linux and Win 7), then the default location cannot be changed at the moment. However, in the newer version available free on Windows and Mac App Stores, you can set the libraries folder to any location, you can also turn the check off if you're using platformIO or other integrated build systems.
|
|
|