[Logo] TCC discussion forum
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Top Downloads] Top Downloads   [Groups] Back to home page 
[Register] Register /  [Login] Login 


This forum is read only and new users cannot register, please ask all new questions either using GitHub discussions, or in Arduino forum tagging @davetcc.

How to update variable values from menu items? getCurrentValue? RSS feed
Forum Index » tcMenu Arduinio library
Author Message
shed


Joined: May 23, 2020
Messages: 5
Offline
Hi all,

I've got some pretty basic questions and probably just need some guidance on using tcMenu.

Basically, I'm just trying to set up a menu configurable timer for 35mm film development, with support for a servo motor to agitate it on a value set also within the menu.

I've got my basic menu set up, which looks a little something like:

Start
Current Settings (devTime, agitFreq, agitRevs)
Set Dev Time
--Minutes
--Seconds
--Save
Set Agitations Freq
--Minutes
--Seconds
--Revolutions
--Save

I've set EEPROM addresses for each of these.

I've declared variables for my 'devTime, agitFreq, agitRevs' in my setup so I can use them within my timer to run functions for to the servo motor, take over the screen for displaying a countdown timer, setting off a beep for nearing to the end of devTime etc, etc.

My questions are:
- How do I update these variables within the function?
- How do I make sure these are saved to EEPROM
- How do I load these specific values from EEPROM on setup?

In my functions for the menu items like Minutes, Seconds etc, I've tried:
void CALLBACK_FUNCTION updateDevSec(int id) {
int devSec = updateDevSec.getCurrentValue();
}

This gives me an error:
request for member 'getCurrentValue' in 'updateDevSec', which is of non-class type 'void(int)'

From what I've read in the forum and the doco, using getCurrentValue should be the correct method.

I guess beyond my current issue, I just want some general pointers on how I go about implementing the timer alongside tcMenu.
davetcc


Joined: Jan 19, 2019
Messages: 686
Offline
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.
shed


Joined: May 23, 2020
Messages: 5
Offline
Amazing, thanks for the info davetcc.

That should get me through, specially the pointer to look at [yourProjectName]_menu.h.

I'll post my results when I get time to revisit it (probably on the weekend).
shed


Joined: May 23, 2020
Messages: 5
Offline
I still haven't managed to achieve saving/loading from eeprom.

I've tried a save menu option that simply includes something like:
void CALLBACK_FUNCTION saveToEeprom(int id) {
menuMgr.save(*eeprom);
}


I'm considering just saving to eeprom on each change within each menu, like:
void CALLBACK_FUNCTION updateDevMin(int id) {
menuMgr.save(*eeprom);
}


I know this isn't the most efficient way, but It might be the most user friendly for my use case.

I'm loading from eeprom in setup(), like so:
// set up the inbuilt ESP rom to use for load and store.
EEPROM.begin(512);
eeprom = new ArduinoEEPROMAbstraction(&EEPROM);

// Load values from eeprom
menuMgr.load(*eeprom);


Should this be all that is needed, or have I completely missed something?
davetcc


Joined: Jan 19, 2019
Messages: 686
Offline
Hi there, never save to EEPROM in the callback function of anything other than an action item, specifically marked as Save. If a rotary encoder is attached, it will destroy your EEPROM in a matter of days. IE every single turn of the encoder during editing will result in a save to your ROM, it will slow down your sketch and use up the 100,000 EEPROM write attempts very quickly. If you are using FLASH as EEPROM which is sounds like you are it will break the board very quickly.

Instead:

Option 1: Provide an explicit option on the menu to save settings, call the save function there, IE a Save ALL option.

Option 2: Follow the example to detect power loss and write out to ROM that's documented here: https://www.thecoderscorner.com/electronics/microcontrollers/psu-control/detecting-power-loss-in-powersupply/

Option 3: Some have started a timer that checks for changes and writes out to ROM only if there have been any changes every few minutes. This would also work pretty well, but you'd potentially still be saving to ROM quite frequently, but maybe no longer dangerously so. You could use taskManager to schedule a fixed rate task for this, and save if a change has been recorded.

Loading back at start up:

Yes, in terms of loading things back, you can just load back from EEPROM during setup.
davetcc


Joined: Jan 19, 2019
Messages: 686
Offline
Also don’t forget that on ESP boards when using the flash as emulated EEPROM, you need to call the commit method after saving the values, as the EEPROM caches values in RAM. The ESP example sketches should help you out with the how.
shed


Joined: May 23, 2020
Messages: 5
Offline
Thanks once again Dave! I didn't realise an each encoder change would save to eeprom, that explains why my board was cracking it.

I've added a save option that also calls commit and it works perfectly.
 
Forum Index » tcMenu Arduinio library
Go to:   
Mobile view
Powered by JForum 2.7.0 © 2020 JForum Team • Maintained by Andowson Chang and Ulf Dittmer

This site uses cookies to analyse traffic, serve ads by Google AdSense (non-personalized in EEA/UK), and to record consent. We also embed Twitter, Youtube and Disqus content on some pages, these companies have their own privacy policies.

Our privacy policy applies to all pages on our site

Should you need further guidance on how to proceed: External link for information about cookie management.