Arduino Menu 3.0

HI,

I was hoping to use an off the shelf menu system for one of my projects, this one seemed to offer some of the best features:

https://github.com/neu-rah/ArduinoMenu

It claimed to work on Teensy so I was hopeful that it would work with STM32

Anyway whilst compiling I get this error:

menuBase.cpp:50:76: error: in C++98 'defaultOptions' must be initialized by constructor, not by '{...}'

config defaultOptions={'>','-',false,false,Menu::defaultNavCodes,false,true};

I changed the build flags in boards.txt to this:

mapleMini.build.cpu_flags=-DMCU_STM32F103CB -DSERIAL_USB -std=gnu++11

Works == Compiles.

The Mini Crashes as soon as any of the input buttons are pressed.

Suspect this is because the menu code overloads a lot of functions.

Other code works fine with the uplifted c++ standard so it’s just this menu system, ah well. The joys of being on the fringe.

OK so I found the cause of the crash, but I’m stumped regarding why.

Perhaps those with more experience may be able to assist?

When a button is pressed the menu fires this event

result action1(eventMask e,navNode& nav, prompt &item) {
Serial<<e<<" event on "<<item<<", proceed menu"<<endl;
Serial.flush();
return proceed;
}

Try to comment out the line with Serial.flush() as it will not work as expected.

stevestrong wrote:Try to comment out the line with Serial.flush() as it will not work as expected.

BennehBoy wrote:stevestrong wrote:Try to comment out the line with Serial.flush() as it will not work as expected.

Quite possibly.

I’ve reported it to the library maintainer, it’s a bit beyond me to debug.

what happens when just printing item? ‘Serial << item<<endl;’
and add a simple ‘Serial<<‘***************'<<endl;’ line to see if it dies there
srp

zmemw16 wrote:what happens when just printing item? ‘Serial << item<<endl;’

BennehBoy wrote:zmemw16 wrote:what happens when just printing item? ‘Serial << item<<endl;’

No it’s a pointer to a class instance, I think basically it’s self referential, the instance of the menu class that is selected passes a pointer to itself to the function, so that the code can say ‘menu item x’ was selected.

It’s not important really because I don’t think I’ll ever need to use that within my menu system.

And yes a debugger would be good – sure the hell beats moving a ‘Serial.println(“got here”);’ about in the code

So it looks like idiot here must’ve done something daft, the code when refreshed from github runs fine on a nano, but still crashes the mini.

Do you mean it crashes on some AVR boards ?

RogerClark wrote:Do you mean it crashes on some AVR boards ?

These flags have been discussed on another thread

http://www.stm32duino.com/viewtopic.php?t=1241

It sounds like they are now the standard for the ARM Arduino build settings, so we should consider using them.

However I can only do limited testing e.g. with my projects, so the proof of the pudding would be just to update the repo and wait for people to complain if it caused side effects

RogerClark wrote:These flags have been discussed on another thread

http://www.stm32duino.com/viewtopic.php?t=1241

It sounds like they are now the standard for the ARM Arduino build settings, so we should consider using them.

However I can only do limited testing e.g. with my projects, so the proof of the pudding would be just to update the repo and wait for people to complain if it caused side effects

RogerClark wrote:These flags have been discussed on another thread

http://www.stm32duino.com/viewtopic.php?t=1241

It sounds like they are now the standard for the ARM Arduino build settings, so we should consider using them.

However I can only do limited testing e.g. with my projects, so the proof of the pudding would be just to update the repo and wait for people to complain if it caused side effects

My project uses H/W SPI & i2C, and a lot of libraries So has another base covered from the i2c perspective.

Victor

Ok.

I will do that.

I will post a replacement platform.txt

Just be aware that on first compile cc1.exe will complain a lot.

BennehBoy wrote:Just be aware that on first compile cc1.exe will complain a lot.

tbh I’m not entirely sure, when the IDE displays ‘Build options changed, rebuilding all’ and does a full compile it appears to pass the std=gnu++11 options into both the c++ and c compilers, the c one (cc1.exe I presume) then just displays a warning saying it was passed an option that is only relevant to c++. Fortunately it handles it well, just might show a lot of warnings that people are not used to.

cc1.exe: warning: command line option '-std=gnu++11' is valid for C++/ObjC++ but not for C [enabled by default]

Incidentally, the menu system functions well other than for the issue with the demo (functionality that I won’t use).

There is an issue I’ve found when using multiple SSD1306 displays however, because a single framebuffer in ram is used for all the displays, and it gets cleared for each screen being drawn, this results in the menu blanking out each time ‘cleardisplay’ is called.

The reason this happens is the author has utilised lazy updates to minimise cpu cycles – ie if the menu has not changed, then it does not output to the buffer. I’m going to ask him if it’s possible to have a ‘redraw all’ or non lazy update added.

The workaround for the time being is to disable drawing to the other displays whilst in the menu – the menu is non blocking, so it was nice to still have the gauges on the other displays visible and updating…

BennehBoy wrote:tbh I’m not entirely sure, when the IDE displays ‘Build options changed, rebuilding all’ and does a full compile it appears to pass the std=gnu++11 options into both the c++ and c compilers, the c one (cc1.exe I presume) then just displays a warning saying it was passed an option that is only relevant to c++. Fortunately it handles it well, just might show a lot of warnings that people are not used to.

cc1.exe: warning: command line option '-std=gnu++11' is valid for C++/ObjC++ but not for C [enabled by default]

Yeah, I probably added it in the wrong place.

I added it to the build flags for maple mini in boards.txt:

mapleMini.build.cpu_flags=-DMCU_STM32F103CB -DSERIAL_USB -std=gnu++11

no complaints if you put it in the compile.cpp.flags line and not the c.compile.flags line in platform.txt
Q also in the STM32F4 platform.txt or just add to all platform.txt files?
srp

zmemw16 wrote:no complaints if you put it in the compile.cpp.flags line and not the c.compile.flags line in platform.txt
Q also in the STM32F4 platform.txt or just add to all platform.txt files?
srp