I keep getting this error when compiling the code for esp8266. I havn't added any of my own code yet just the output from the designer app.
Any suggestions would be appreciated.
Thanks

Hi there, I'm assuming that you've selected Serial transport for remote control. Up until now, I don't think anyone has used Serial on these devices, most menu's up till now have used WiFi.

This seems to be because the ESP8266 Stream.h class is lagging significantly behind the true Arduino implementation.

I'll raise a bug report for the designer UI to conditionally change this to use "available" for ESP8266 boards (and I'll check ESP32 while I'm at it). There's a patch release to upgrade IoAbstraction with new features due soon, I'll add this to that release.

This is unfortunate because the semantics of the two methods are very different and it means on lower speed serial connections with a lot of updates (100-1000 per second range), you could risk locking up the board when serial blocks because it can't write. Although this is unlikely in most applications to be fair. I've tested the protocol down to 9600 baud, and it doesn't even saturate in most normal cases.

One possible tempory workaround (that needs to be repeated after designer code generation):

Open SerialTransport.h

change line:

virtual bool available()     { return serialPort->availableForWrite();}

To:

virtual bool available()     { return serialPort->available();}

Thanks, I actually selected "ethernet control over esp8266 wifi" not serial communication. Will try the workaround while waiting for the updates. Cheers.

See https://github.com/davetcc/tcMenu/issues/61. This will be fixed in the upcoming patch release. I've got an ESP32 and an ESP8266 to hand, so I'll generate menus on each after putting the designer UI change in place.

As an aside, the number of boards I've built up trying to test different functions is quite considerable

Thanks, that's a great help to get me on the way. I can only imagine the amount of different hardware possibilities for testing. I appreciate the time and effort.

Can you check in your project if you have SerialTransport.cpp / .h in there?

It's the only place in the project that availableForWrite exists.

If so, you could have inadvertently chosen serial at some point. It doesn't delete the plugin files if you change from one to the other.

If you're sure you are not using the Serial connector, you can probably go ahead and remove SerialTransport.h / cpp if they are there. If it turns out you are using them, the designer would put them back for you anyway.

Thanks,
Dave

ahhh. Thank you, that explains everything, i made some messy tests in the beginning and presumed it would change everything if i re outputted the code from the designer. Perfect. Thanks so much, i won't be using serial as i need that for other components in the project anyway.

Great, thanks for confirming, I'll fix the serial class in the next release as it should work.

There's an open issue for removing existing plugin source code when no longer in use, but the issue is, how can the designer do it safely.

My current thinking is to make a list of all the plugins when the designer is loaded, and if they change then offer to remove or rename any files that are no longer needed.

Sounds like a good idea as it stumped me for a few days and couldn't find it documented anywhere. Some sort of plugin final check would do. Thanks again.

Thanks agreed that this is not well documented, I'm going to try and implement an initial pass at this in 1.3.5.

I'll update the documentation around plugins a bit more once I've got this change in there.

See https://github.com/davetcc/tcMenu/issues/30 which has been moved to 1.3.5