Go Down

Topic: MENWIZ: yet another character lcd menu wizard library (Read 113786 times) previous topic - next topic


I will suggest you:
1- Load EEPROM erase programm from the Arduino IDE and erase the existing EEPROM in your arduino.
2- Then upload your GAME sketch  and first save the EEPROM values.
3- Now just open another sketch from Arduino IDE that load the variables and display on Serial.Print.
4- This will ensure that your Read and Write EEPROM functions doing well.

I actually load the EEPROM variable once just start of the Arduino so that all the variables get the parameters from stored values. If i add another variable in the sketch then i first erase all EEPROM using above method. Then i disable Load EEPROM function in my Setup menu. Then i run the sketch and Save the EEPROM. Then i again enable the save EEPROM function in setup menu.
Simply...You can't afford me..

Author Of:

Oops..some one gave me Karma...:)


Jan 12, 2013, 10:50 am Last Edit: Jan 12, 2013, 12:54 pm by brunialti Reason: 1
The use of eeprom methods is up to the programmer. That is not because I'm lazy :-) but because other approaches could lead to errors very difficult to bug. For instance, If you change the sketch code inserting new variable between the previous variable set, when you use readEeprom some variables  get true values and other do'nt. Forcing range values could have no sense at all in a sketch application, where parameter are often related.

There could be an other way: prepend in eeprom to the first variable a user defined check mark (likely the sketch version number)   providing a method to verify if the actual eeprom contain the expected value for check mark. If it is equal it means that reading from eeprom make sense, otherwise the sketch will use the default var values: the two added method could be:
void setCM(int);
int getCM();
It is up to menwiz to shift the memory read/write after the check mark location  

Yes docs could be improved.. should I have time. Any help is wellcome.


I think I understand.

Maybe I should set up a set of #define like D_GAMETIME etc as the default values.

I'll declare all the variables but not initialise them. I could use a version number to do a check of whether anything has changed. Read EEPROM, check version number in EEPROM against #define, if the same then values are all valid and must have been saved previously. If not equal the. EEPROM is either empty or out of sync with version, so clear EEPROM and load default values. I'll think it though better.

I'll put the version number in my Developer menu and also a 'Clear Saved' and 'Load Defaults' option.

Is there a way to have a read-only menu option? This could be useful for allowing the user to display the version number or author etc.

I'll be using this on a 1284P, which will give the PROGMEM and RAM to implement a comprehensive settings menu on top of my existing project code and all the various options.

Another thing that has occurs to me is an expansion of the increment value option. If the up/down key was the default to increase/decrease a value, then the left/right keys could be used to jump up and down by a larger amount. This would require an additional argument. For example, my gametime variable is from 1-5999 (00:01 to 99:59). If I could specify (1,5999,1,10) to allow up down arrow to increase/decrease by 1 and left/right to increase/decrease  by 10, it would be much more flexible for large ranges.

I see in the code provision for a future text item. Again, that would be very useful for me to allow a user to enter themselves as registered owner, or set the device for the name of the game and the location name of the device.


Jan 12, 2013, 02:20 pm Last Edit: Jan 12, 2013, 02:31 pm by brunialti Reason: 1
Why a read only menu ? You can create a splash screen for 5-10 seconds at startup with all the usefull infos. It uses less memory
If you prefer to code a menu entry ... create a dummy action variable, with an empty callback and set MW_ACTION_CONFIRM behaviour to false

Differentiation of  increment steps for variable limits would need one more pointer in the var structure. many users (e.g. see github) claim about the memory used by menwiz variables... EDIT: the proposed solution also would be usable with 6 buttons only

Yes, Im' trying to imagine a implementation way for imput fields. I need to find some clever way to write compact code. the menwiz footprint is dangerosusly near the usability border.


I've coded a dummy var into the menu to support a 'very' variable containing a current version.

I've also set a #define of D_VERSION as a comparison.

Now, on start I declare all my variables, without values, and a corresponding #define D_ value as the default.

I then set the menu structure up and do a readEeprom. From here I check to see if ver and D_VERSION are equal. If they aren't then I run a loadDefaults() function that assigns all the D_values to the corresponding variables and then does a writeEeprom to set the defaults in EEPROM.

Now, this should mean that on the next reset the 'ver' loaded from EEPROM is the same as D_VERSION and the loadDefaults() doesn't run.

This never seems to work though and defaults are always loaded. It's like the Eeleom is being written too.

A friend said he had a similar issue when using the standard EEPROM library and it was only. Heed when he wait he'd to EEPROMEx.

EEPROMEx has an update() method where it will  check the contents of each address and only update if the data has changed.

I need to debug the issue I'm getting anyway, but I'm thinking of trying to modify the library to use EEPROMEx (it's backwards compatible with EEPROM library) and soecifically the writeEeeprom method to actually use the update method In EepromEx library to save wear on the EEPROM.


The other thing I meant to say; from a memory management point of.view, the smallest data in MENWIZ is an int. this is two bytes. Many of my variable values. An be contained in a uint8_t, which is half the size, but MENWIz will use an int for these values.

That's maybe a potential place you could save on some memory by allowing a smaller variable to be used. It could potentially save quite some space for some menus.


The smallest variables in menwiz are MW_BOOLEAN  e MW_AUTO_BYTE. each one allocates dinamically 1 byte for  any required internal structure member:

typedef struct{

  MW_TYPE  type;
  void*    val;  //pointer to use variable
  void*    old; //old value
  void*    lower;  //lower limit
  void*    upper; //upper limit
  void*    incr;   //increment step



about default values: define default values as you declare your variables. As menwiz point to the user variable (and do not change its value at addVar time), you'll find your default values untouched. You do not need a default assignation function;
The eeprom check and mark management will be in next version of menwiz.


Something strange happened:
when I try to compile the same sketch I always used I got this errors.
If I change computer, the sketch work flawlessly. I reinstalled the libraries needed on the first pc but nothing (two days ago the same file on same pc had no problems).
Any ideas ?
In file included from sketch_jan21a.ino:7:
C:\Programmi\arduino-1.0.3\libraries\MenwizB/MENWIZ.h:134: error: 'Button' does not name a type
C:\Programmi\arduino-1.0.3\libraries\MenwizB/MENWIZ.h:135: error: 'Button' does not name a type
C:\Programmi\arduino-1.0.3\libraries\MenwizB/MENWIZ.h:136: error: 'Button' does not name a type
C:\Programmi\arduino-1.0.3\libraries\MenwizB/MENWIZ.h:137: error: 'Button' does not name a type
C:\Programmi\arduino-1.0.3\libraries\MenwizB/MENWIZ.h:138: error: 'Button' does not name a type
C:\Programmi\arduino-1.0.3\libraries\MenwizB/MENWIZ.h:139: error: 'Button' does not name a type


Jan 21, 2013, 07:01 pm Last Edit: Jan 21, 2013, 07:03 pm by brunialti Reason: 1
the ide does'nt find buttons.h library include.

That is:
- or your sketch does not include the file
- or the library is unreachable by the ide

in MENWIZ.h, if it is defined BUTTON_SUPPORT, there are instances of type Button in the referenced lines.


- or your sketch does not include the file

yes it does ... it compiles perfecly on another computer ...

- or the library is unreachable by the ide

it's in the right location ... I also reinstalled .... so I think last chance is to reinstall the IDE ...


I had this same problem and found that my copy of the menwiz.h library was different on the other computer. I usually copy my files onto a usb drive to move them between computers. I somehow managed to get a copy that did not have the #define BUTTON_SUPPORT line commented out. So if you don't have #include <buttons.h> in your sketch and the menwiz.h calls for it you get the error.


I broke my  LCD, while waiting for the new one, I would like to know if it is possible to simulate the LCD output on the Serial Monitor on the PC, so I can check if my sketch is working ( I just want to see what is displayed on the LCD).
Something like the second example in this page ...

Hi stretched59, it's a good idea ! I will try it.


sorry, no serial simulation available.
as the lib displays for each draw call, it could produce a lot of serial output.
As far as i understand that library has e different implementation


Jan 29, 2013, 10:26 pm Last Edit: Jan 29, 2013, 11:33 pm by aufruf Reason: 1
Hi all,

Looking for a nice and simple library I have found MENWIZ and hence would like to test it for my project. Unfortunately I face some issues setting up my LCD. Currently I still use the included LyquidCrystal library with my DFRobot LCD Shield.

This is what I use for initialization:

Code: [Select]
LiquidCrystal lcd(8, 9, 4, 5, 6, 7);


  • 8 for RS

  • 9 for E

  • 4 for D4

  • 5 for D5

  • 6 for D6

  • 7 for D7

What would be the equivalent for the New LiquidCrystal library?

Code: [Select]
LiquidCrystal_I2C lcd(???);

Do I need to remove the LyquidCrystal library from my libraries folder or can they coexist?

Many thanks in advance!

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131