Message |
|
Haha, I have those moments when I'm programming all the time (although, in my case things bug out and I wonder "how did I ever think that would work!?".)
I don't know if it's helpful, but I did attach the font file I'm using since I have edited some of the characters to display custom icons or characters that aren't in the default font (specifically: ~!@#$ have been changed.)
I'm using a 3.2" 320x240 ILI9341 display module.
The only other change I've made is to adjust the padding in the generated ThemeCoolBlueTraditional.h
MenuPadding titlePadding(5); // Custom padding
MenuPadding itemPadding(3,10,2,2); // Custom padding
This may be at fault (?)
Thank you very much for posting all these updates. All your hard work is greatly appreciated.
|
|
|
Thanks again Dave!
I'll keep an eye on the Github issues.
For the encoder overflow, since I'm not actually using IOA to get the encoder values, I expect I just need to continue using my workaround to make sure I don't exceed that increment number, but I'll look into checking the allowable range/maximum value to see if I can make the workaround a little less clunky. Thanks for the tip!
As always, please let me know if I can provide any further info to help nail down the other issues I'm seeing. I'm happy to help where I can.
|
|
|
Excellent, Thank you!
Update:
I just saw that tcMenu 2.4.0 is out. I went ahead and updated that (along with IOA)
Issue 1: Improved in that now it always selects the OK button instead of the title bar, but still doesn't seem to allow me to change the default
Issue 2: Still exists, but is less obvious because of the new behavior of Issue 1.
Issue 3: Seems unchanged. My workaround still works just fine.
----
Bonus Issue 4: Absolutely LOVE that values of 0 in Large Number menu items don't show up empty anymore, and I like the underlined digit indicator better than the way it was before, but the alignment of that indicator seems to be off. In the attached pic you can see that I'm currently editing the left-most digit (2) and the indicator isn't really under that digit. This continues all the way to the last digit where the indicator is off to the right, and pushes all the digits a bit to the left. I tried changing my margin settings thinking that maybe it was expecting the default values, but that didn't seem to help.
|
|
|
Hey Dave et al.
I'm nearing completion of my project and it has been an absolute pleasure working with these libraries. Everything I've wanted to do has been provided and any bugs I've discovered have been squashed! Thank you!
There are just 3 little things that I would like to tidy up and I can't seem to find good workarounds to 2 of them. The 3rd thing I believe is a bug, which I have shown a workaround for below (but maybe there's just a better way to avoid the issue in the first place). I can provide extra code if my examples aren't clear enough. I would appreciate any insights into these issues at your convenience. All issues are with latest version of TCMenu and compiled with PlatformIO for Teensy 1.57
1, Cannot select the default button in a BaseDialog screen
Not much more to it than that. I can put 0,1,2.... in the final parameter of my setButtons() function, yet the title bar is always highlighted regardless. Maybe something to do with manually controlling menu navigation with my buttons/encoders?
void CALLBACK_FUNCTION onDiscardExit(int id) { // Dialog to confirm exiting menu without saving
BaseDialog* dlg = renderer.getDialog();
dlg->setButtons(BTNTYPE_OK, BTNTYPE_CANCEL, 0); // <-- This number does nothing for me
dlg->show(exitHeader, true, confirmExit);
dlg->copyIntoBuffer("Discard changes?");
}
2, Doubling of highlighted items in BaseDialog screens
Again, using custom functions to navigate the menu. Problem arises when using the following code for a specific button in my onSwitchPressed calledback. If I've got anything other than the OK button (as defined in issue 1 above) highlighted, the OK button becomes highlighted IN ADDITION to whatever was previously highlighted. It's always the OK button, regardless of which I have chosen (as per issue 1.)
Back button snippet:
if (!menuMgr.getCurrentSubMenu()) { // In root menu?
onDiscardExit(1); // Exit without saving?
} else { // In submenu
menuMgr.performDirectionMove(true); // Go up a level (this is what messes up the confirmation screen)
}
3, Overflow issue when pushing big number into increment() while editing Large Number menu items.
Due to issues with needing FAST rotary encoder counting, I have the encoder connected to a secondary device (ATTiny85) which I'm polling over i2c to get my encoder counts when my main program (running on a Teensy4.1) isn't too busy. The function that gets this number uses some multipliers to allow for an accelerated input when turning the wheel fast. The problem comes when these big numbers are used while editing digits in Large Number menu items. I can get some kind of overflow which changes the digit into non-numeric values and even effects adjacent digits (things like: =>;: show up instead of numbers)
The code that was causing issues:
int16_t i = getEncoderAccelerated(); // Get encoder movement from ATTINY85 over i2c (usually around -512 to +512)
if (i!=0) {
switches.getEncoder()->increment(i);
}
The work around (Any better way to handle this?) Seems like it should be constrained internally if big numbers cause this kind of problem.
int16_t i = getEncoderAccelerated(); // Get encoder movement from ATTINY85 over i2c
if (i!=0) {
if (menuMgr.getCurrentEditor()) { // If I don't confirm that I'm editing something the Teensy hard crashes on the next line
if (menuMgr.getCurrentEditor()->getMenuType()==MENUTYPE_LARGENUM_VALUE) { // Check for editing Large Num
i=constrain(i, -1, 1); // Solves bug where large num digits overflow from fast encoder movement.
}
}
switches.getEncoder()->increment(i);
}
I hope this all makes sense and can help you make these great libraries continue to improve. Please let me know if there's anything else I can do to assist in resolving these 3 issues.
|
|
|
Very cool! You're awesome Dave. Thanks so much for your help.
|
|
|
Hi Dave,
Please forgive my ignorance, but I'm not sure if you're asking me to add anything specific to the "do your work..." area in the code snipped you gave. I replaced my menuMgr.load line with yours as written (but added the default magicKey of 0xfade) and found no change in behavior.
But to be clear, I'm also seeing the blank column immediately upon exiting the value-editor after having toggled the value back to zero. This doesn't seem to be directly related to saving/loading the value from EEPROM.
Likewise, I continue to see a blank line in the value column of these menu items even if I had a non-zero value saved already, and then change the value back to zero. This display of the blank column persists through reboots (loading the saved zero value from EEPROM).
In other words, I NEVER see "0" in that column at any time, regardless of reboots/reading from EEPROM, OR even just while navigating the menu before saving any changes to EEPROM.
Please let me know if you'd like me to try anything else. I'm happy to experiment if it can help you.
Thanks!
|
|
|
Ah! excellent, I set the right margin to be a few more pixels than the other sides and now things are looking real sharp (The extra pixel shift of the number 1 is barely noticeable when everything is 6 pixels from the edge already) Thank you!
Regarding the empty lines for 0 values on large number items, I'm surprised no one has noticed already, since a new project seems to default the value to 0 on any item that doesn't yet have a different value saved in EEPROM. I'd be very curious to know if I'm somehow the only one seeing this issue, and how I might rectify it.
Thanks again for the advice! Your help is very much appreciated.
|
|
|
Thank you Dave,
I'll look deeper into the observer functions, but at a glance it looks like it might be more trouble than it's worth for my use case.
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 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.)
Thanks again!
EDIT: Whoops, the darn thing shows up in Australia mode on the forums. If you download it, you'll get a clearer view and it should be right-side-up.
|
|
|
Hello all!
I just ran into a couple of concerns and I was wondering if anyone knows a workaround or further options that I haven't been able to find in the documentation/forums:
I just setup some "Very large numeric values" in the tcMenu designer, but I'm noticing that they don't function the same way that normal int/float items work.
Primarily, I see that if I set them to "0", they aren't displayed in the menu at all. Once I set them to anything larger, I can see the value in the menu items list as normal. Is there a way to display "0" values?
Also, I would like to set a limited range of values that these items can take (similar to int/float items,) Example: 0-1,000,000. However, if I set the item to have 7 digits, there's no way to limit the user from inputting a number larger than 1 on the left-most digit. In this case, I'm actually okay setting the limit to 6 digits (999,999 is close enough), but it would be nice to have such a feature if possible.
When working with these items, just using a setCurrentValue(int) would make this much more intuitive. I'm not sure why we have to use strings, but it works, so no big deal.
----
Regarding margins, I have found some properties while digging through the source code regarding position of menu values, but I can't seem to get anything to work by changing these values. What I'd like to do, is push the menu item values a pixel or 2 off the right edge of the screen (ili9341 in this case) so that they have a little breathing room. This is just an aesthetic preference, but some characters with long vertical lines (M, I, etc.) on right side do appear to be slightly cut off/crowded at the moment.
As always any insight and advice is greatly appreciated.
Thank you so much!
|
|
|
I upgraded my libraries to the latest (same versions as your list above) and everything compiled/runs fine in my project.
Thank you!
|
|
|
Hi Dave, I did look into that. The main issue is that when I'm moving the jog wheel I need to actively be sending updated commands to the servo drive as fast as possible (10-15 times a second seems to be a sweet spot), so if I'm sending serial commands that often (available or not) they will be interfering with the next encoder input that I need to be looking at... Kind of a chicken and egg scenario I suppose. I am also requesting/receiving servo position information from the servo drive several times a second, AND this is all eventually happening with 2 separate drives/servos. So there's very little, if any, time that I'm not relying on constant serial data.
I did look into multi-threading, but it seems that with the single core CPU of the Teensy, I can only just divide up my tasks into time slices (100ms by default which is way too coarse), but even with shorter slices, there's a big caveat regarding Serial in that I need to lock (mutex) such commands so that they have time to finish, which of course negates the whole potential advantage for my use case. There are full on RTOS packages I looked at, but it quickly started going over my head. Perhaps something to keep in mind as I advance my skills.
Since it's what I know, and what I had available, I did setup a Teensy that I was able to bodge in to my circuit for testing. My screen updates are only happening 5 times/sec as per my tcMenu settings, and I'm querying the cumulative count about 10 times/sec over i2C. This result either gets fed into my motor equations or into a call to the encoder increment() command for working with TcMenu navigation. I'm using Paul Stoffregen's encoder library which is very fast/efficient for in/decrementing the count. The count gets zeroed on each query for the next time. In practice this is actually working out very well. The system is the most responsive I've seen it and I am getting my commands out without interfering with anything else (all my buttons on the IOExpanders obviously don't need such rapid synching, so the rest of the IOAbstraction stuff is working great.)
This "Multi-Core" approach isn't the most elegant, but I'm going to need to update the PCB design anyway, and a tiny85 is only $2, so I'm tempted to stick with it. At least for now.
Thank you again for all your advice.
|
|
|
Thank you very much for your comprehensive answers.
I wasn't able to find a Serial library that seemed to be non-blocking, but there is a well regarded TeensyThreads.h library which supports the std::thread function as you suggested. I'm gonna have to jump down that rabbit hole to figure out how to implement it as I'm definitely not used to working with these more advanced types of functions and thread-safe programming. It does appear to have good documentation and examples so I'll see what I can do.
Am I to understand that this could allow the CPU cycles to be divided up in a such a way that the i2c calls in the TaskManager for my encoder could still sneak in during Serial TX/RX taking place on another thread? That would be great!
Not knowing much about multiple threads as a software solution, I was considering doing something I've done in the past, where I have a dedicated ATTINY85 purely as an encoder counter which in turn is set up as as an I2C slave I can poll for cumulative counts when needed. Looking at my data capture above I see that the I2C calls are relatively fast compared to the Serial signals, so it may be possible to keep everything running well enough since I've divided my tasks with hardware instead of software, but that'd of course take bit of new hardware to design/test out.
Edit: I guess I would then have to feed that number back into tcMenu somehow for jogging through options and changing menu values. Not sure how that would work yet.
Either way, I've got plenty to look at now. Thanks again!
|
|
|
Hey all,
I got an issue which I don't believe is actually related to a malfunctioning of this library, but perhaps a limitation or conflict between the UART/I2C/Interrupts on my Teensy 4.1 or perhaps just the nature of Serial comms on Arduino.
Quick setup summary:
Teensy 4.1 with 1x 23017 and 1x 8574 on the same I2C channel (Yeah, I need lots of I/O)
3x Serial Ports for Modbus communication: 2x servo drives and 1x for receiving commands from a PC.
Most of the I/O expander pins are being used for button (19x) & encoder (1x) inputs using a separate interrupt pin on the Teensy for each expander.
And then most of the remaining non-UART/I2C/SPI pins on the teensy are going to LED and SSR outputs.
In the attached image I have captured a segment of the system all working together with my logic analyzer. You can see that when the serial commands are being sent to the servo drive, the INT pin of my 23017 (where my encoder lives) doesn't get reset quickly. This causes encoder ticks to get missed by the ISR.
In this example, that's actually not a huge deal because the serial command is only going out twice a second. But in the final operation of this system, I will be sending serial commands closer to 20x/second with each of the two serial ports going to the servo drives.
In practice this makes my encoder input almost unusable. I have a very short onEncoderChange() callback which just increments a variable that I then use in my main scheduled task to calculate what commands to send to the servos, so I'm not sure what else I may be able to do to mitigate this issue.
For example: Would moving my encoder to direct interrupt-enabled inputs on the Teensy help?
I'm working on a prototype PCB which marries all this stuff together, so I don't want to go cutting traces and bodging wires until I have some guidance from someone wiser than I.
Thanks in advance and sorry for posting another long winded thread.
Any insight is always greatly appreciated.
|
|
|
I just posted an issue about this exact error this morning on Github, but then I closed it because I noticed that my tcMenu version was only 2.2.4. There is a 2.2.5 on Github which doesn't cause this error, but it's obviously not being pushed to the masses yet. You can either manually upgrade tcMenu to 2.2.5 which seems to be working normally as far as I can tell. Or you can downgrade IOA to 2.0.6. I imagine that Dave will have all the kinks worked out when our library managers let us know about the new version
Hope this helps.
|
|
|
Very cool. No hurry on my end, but glad it's working out so far.
Thank you so much!
|
|
|
|
|