Go Down

Topic: OpenMoCo Menu Manager - completely automated menus for Arduino (Read 17 times) previous topic - next topic

shkdxb

Thanks drone, i could able to solve the issue. For a strange reason, the libraries are not recognized under default library/ folder. While compiling, the error showed up for library location as my documents directory. i have copied your files to my document/ aruduino/library folder and problem solved.

But now i have one more issue. As per your documents, you have EEPROM support, but the example provided in your Github page doesn't have this line in line no 78.

MENU_VALUE foo_value = { TYPE_BYTE,       100,   0,     MENU_TARGET(&foo), EEPROM_FOO };

Also i could not find the setup parameter OM_MENU_USE_EEPROM.

how can I implement EEPROM writing and reading?

drone


hi
i am getting error when try t compiling this example OMMenuMgr.ino.

'BUTTON_SELECT' was not declared in this scope.

any help?


Sounds like you did not properly install the library, or include it in your sketch?  BUTTON_SELECT is an enum defined in OMMenuMgr.h

shkdxb

hi
i am getting error when try t compiling this example OMMenuMgr.ino.

'BUTTON_SELECT' was not declared in this scope.

any help?

macsimski

Hey there,

the lib looks promising. I stumbled upon this when i was wading through the code for chronos, not liking it a bit. But what i liked about the chronos approach was the input of data through potentiometers. it is fast and with a small piezo as audio feedback even tactile. but how to incorporate this into the openmoco menu manager?

Thinking aloud here it could even be possible to use just one analog pin for the hole setup, attaching the pot to vcc and gnd via two resistors, so two extra buttons can short the analog pin to vcc or gnd as button values.

But i'm just a moderate c programmer, still not able to handle the abstract thoughtsbehind c++, so don't expect any code from me. :-(
--
"We're all in this together..."

drone

Hi Mike,

Sorry for the delay!

The issue is not really debouncing, but the checkInput() method does a lot more than that - you'll note that it handles escalating values the longer an input is held, dealing with returning back to menus from screens, etc.  To handle a sixth input will be a bit more complex, because you probably want that input to behave like two of the other inputs. (e.g. emulate INCREASE or DECREASE based on direction of turn.)  The best way to do this will be to modify the OMMenuMgr library file and make _checkAnalog() a protected virtual, and then sub-class the OMMenuMgr library, providing your new _checkAnalog() function to properly return the button type.  This way, you can make your own _checkAnalog() method that returns one of BUTTON_NONE, BUTTON_FORWARD, BUTTON_BACK, BUTTON_INCREASE, BUTTON_DECREASE, BUTTON_SELECT based on how your inputs are read.

You may also want to make setAnalogButtonPins() virtual as well, so you can pass the correct information in without hard-coding it.  If you're still interested in doing this, I can make these virtual changes to the core library so that you won't have to worry about upgrades later.  BTW, the new home for this library is: https://github.com/DynamicPerception/OMLibraries

!c

Go Up