Message |
|
As far as I can tell, the archives should be OK, they are tested on Catalina before publishing (in fact they are built on Catalina on my developer mac book pro). However, I'll ask my tester to try it again now.
The big issue is that they are not Notarized and so very, very difficult to install on Catalina. Can you confirm what error you see?
Feel free to contact me using the contact form from the main site, to expedite things.
I am in the process of renewing an Apple developer license, and the good news is that once re-instantiated, there will be a Notarized UI soon after.
A native designer that will be in the App Store is just about finished development-wise and going into testing now, this will hopefully be listed on the app store (as per windows).
|
|
|
1. It looks like I could schedule a task to read from the serial line every xxx ms.
Yes, that would probably be quite straightforward to achieve, there's lots of examples in IoAbstraction of creating tasks. Just make sure that you don't do any blocking IO in that call, IE call available() before read().
2. Seems like it would not be efficient to take over the display on every character that I receive. Is that the best practice or would a different approach be advisable?
It's up to you, many take over the display at startup and only give the menu control when a "menu" button is pressed, to help with this there's also a reset timer, that can be set up to call you back when the menu is idle for a given amount of time (defaulting to about 30 seconds).
|
|
|
Hi Mark,
I assume by this we are talking about taking over the display so that you can leave the menu and render your own data.
In that case I'll discuss this in terms of the rendering function callback:
1. Is this possible using just one encoder? While in the function, I want to process the encoder. When I exit this callback function, I want the menu to re-engage and take over the encoder input.
During the take over display rendering function you are passed an integer as the first parameter and a boolean as the second, this is the current value of the rotary encoder and if it is pressed, during the setup of taking over the display, you can change the precision of the encoder to represent a different range.
2. The plan would be to use the encoder switch to exit from this subtask to get back to the menu system. Is that button event something I can capture in the processing function?
As per above the button press is captured by the second boolean parameter in the take over display call back.
3. Aside from exiting the callback function, should I be executing any tcMenu function prior to exit?
The take over display callback is actually a task from taskManager, it's repeatedly called so you should be rendering once then letting the function exit. When you're ready to give back the display to the menu, call renderer.giveBackDisplay()
4. Can I use the same "lcd" variable for displaying the results as used by the menu system?
Yes, but only in the render callback, never use it in any other task or when the display has not been taken over.
See the takeOverDisplay example that ships with TcMenu, that does most of what you're looking to do here.
Thanks,
Dave
|
|
|
That's fully supported by tcMenu, including handling timeouts to leave the menu back to your own display renderer. The only limitation is that you manage your screen in a game loop style, where you're called frequently and should do any rendering in that loop.
See the takeOverDisplay example shipped with tcMenu that does pretty much what you want.
https://github.com/davetcc/tcMenuLib/tree/master/examples/takeOverDisplay
|
|
|
Hi there, at the moment taskManager cannot handle events that are not either interrupt-driven or timed. I have a plan to add timed events that can be replaced so there's only even one of a given ID on the queue, but I've not really considered a more generic eventing framework. I'm not 100% sure how that would work to be honest. I'm open to discussion on it though.
|
|
|
That's a lot of code to try and debug. It's very hard to debug that much code at once. Couple of things I noticed, firstly, there seems to be a lot of expanders sharing the same interrupt pin. I've never tried 64 pins / 8 expanders sharing one interrupt pin.
I'm assuming at some point it was working and then stopped working.
What I would do, is keep commenting out functionality in the code until you get back to a working solution. Leave all the hardware in place and try to get functions working in isolation, by commenting / uncommenting sections of code. Maybe just one switch and one rotary encoder, get that working and then introduce another encoder and so on. I would work through all the pin numbering that you are using carefully. You may be hitting some limitations somewhere but with such a complex sketch it's really hard to determine what's going wrong.
|
|
|
Loading from EEPROM, you'd normally do this during setup by calling menuMgr's load method.
Saving to EEPROM, for this there are two ways, the usual way is to use a power loss circuit that detects when power is lost and immediately saves to ROM. The other option is to have a save option in the menu. See https://www.thecoderscorner.com/electronics/microcontrollers/psu-control/detecting-power-loss-in-powersupply/
To access the value of any menu item you use its accessor function. Menu items are declared with menu followed by the name with no spaces in camel case. For example menuUpdateDevSec. For AnalogMenuItem and EnumMenuItem that's getCurrentValue, for BooleanMenuItem that's getBoolean. For other types of menu items look at the reference guide: https://www.thecoderscorner.com/ref-docs/tcmenu/html/classes.html.
The best thing to do is to open the [yourProjectName]_menu.h and have a look at the menu items it generates for you.
|
|
|
Not exactly the same, but you could implement this in a similar way to the text editing, but with custom handling for your telephone numbers.
You would essentially look at the existing runtime menu function handlers and write a similar one for your purposes. I suggest you take a look at how the existing ones implement the required callback function. Take a look at the text menu item and its callback function:
https://www.thecoderscorner.com/ref-docs/tcmenu/html/class_text_menu_item.html
The callback function is textItemRenderFn implemented in src/RuntimeMenuItem.cpp
At the moment the designer does not support custom classes so you'd have to add them to the menu yourself at runtime (easiest to put them at the end of a menu by pointing the last item's next to this and setting the custom item's next to NULL). You'll see this done in many of the examples.
We'll need to think about how these can be integrated into the designer plugin system, probably by providing an XML definition of how to generate the code for these at some point.
|
|
|
I've also just set 1.4.3 of the plugins (containing ssd1306Ascii driver) to be the standard now, so you can go back to using the STABLE release stream if you like.
|
|
|
lololo wrote:I don't quite understand if you have to initialize the rotary encoder in the setup? I just put the pins in tcmenu before generating the code. it works (but not very well) and the click does not work. ?!
There should be no additional configuration needed beyond what you've defined in the code generator. Which board are you using? Are you using long wire runs? Does the board allow for input pull up on those pins.
Ensure to start with you have interrupt_switches set to false and pull up logic set to true. Also don't forget that PIN A of the encoder has to be an interrupt capable pin, either on an IO expander or Arduino Pin. I'd start out with an Arduino pin and build from there.
lololo wrote:I also wanted to know if it is possible do not display the name of the application on the screen?
Not out of the box at the moment. Don't forget that the rendering class is nothing more than a file placed in your directory. Longer-term you could customize it, there's even a guide for that.
lololo wrote:and one thing that would be nice, is to be able to enter Setup mode by making a double click (which would make it possible do not display setup on the main screen and win a line)
You can do this, take a look at the takeOverDisplay example. It starts in a custom screen, then goes into the menu when clicked. You can essentially choose when your code or the menu code controls the screen using takeOverDisplay and giveBackDisplay. When you call "take over display", you provide a function callback that will be called several times a second to refresh the display if needed. Similar to a game loop basically. Never render to the display outside of this function.
Hope that helps,
Dave.
|
|
|
Supporting a new framework adds significant cost and complexity to our testing and release procedures. Each one has to be carefully weighed up in terms of cost vs benefit.
For PlatformIO and mbed, it's easy to see the benefits, as many people have already requested support for these boards.
I've opened a new topic to allow discussions around it. To see if there's enough take-up to warrant the development and testing effort
|
|
|
From manmln:
Do you have any plans to make tcMenu available for Particle devices?
---
This is Arduino compatible IoT device.
https://www.particle.io/iot-platform
These are datasheets for devices
https://docs.particle.io/datasheets/wi-fi/argon-da...asheet/#functional-description
My particular interest is for Argon and Xenon as they both have WIFI and can use same libraries. Photon is outdated. Boron and Electron are cellular.
---
Do you plan to add Particle support (as I requested before in this thread) to this release?
I would really appreciate if it is included. I am sure there will be many users for it.
|
|
|
Many thanks lololo, as far as the SSD1306Ascii goes, I think I'll have something soon. I had to order some more OLED display as I have to keep swapping them between boards now, as I like them so much.
Here's an in development example.
|
|
|
Could you not just wrap the callback and check if the held status is true, ignoring it.
eg
void onButtonDown(uint8_t pin, bool heldDown) {
if(heldDown) return;
do other stuff
}
|
|
|
|
|
|