Undocumented use of Tcmenu to allow dual embedded UI with e.g. LCD and encoders on two Mega2560 boards.

[AtmosphEng]

I tried an experiment today with TWO virtually identical Mega2560 boards with their own LCDs and encoders. Both boards were programmed with identical software, with the Tcmenu Designer Code Generator set to enable external Serial interfacing on the same port of Serial2. A three wire interface of 0V, and a crossover of the Tx and Rx UART cabling was connected between the boards.
The result provided half-functional dual control locally.
Is such a use case supported and/or sensible with Tcmenu, and if so does anyone have any guidelines or hints to bring it to full functionality.? Both boards have the same Product Unique ID code, is that another issue? I actually had in mind replacing the crossover cable with two ESP32s to provide a semi-local wireless BluetoothSerial link, but I tried the crossover cable first.
Thanks for reading.

[davetcc]

I mean this is not a case that I've really considered up until now, but yes having two such boards with the same ID needs to be supported even with the regular remote facilities as the ID is supposed to indciate what kind of device it is, for remote control I normally use the standard remote protocol in tcMenu, but there should be no issue implementing your own and roughly following what the default does.

Maybe there also needs to be a serial number as an int32 that is also sent remotely, maybe this could be a weakly implemented method that by default always returned 0, and could be implemented in your code to do otherwise. Along with the UUID the system would then be fully unique per board if needed. Those who didn't need it, would leave the weak implementation.

[AtmosphEng]

Thanks. It was an interesting experiment which potentially provided dual-control with identical embedded hardware boards and software i.e. with no further development required. The first board had all embedded UI plus wiring to actuators, and the second board has just the embedded UI e.g. LCD and rotary encoder(s). In practice I found that some customisation of not sending some menu items remotely was required and I noticed some doubling of actions also occurred e.g. if a menu item had associated setCurrentValue() code which added 1 to an LCD variable, then each board added 1 so the overall result was to add 2 instead. Maybe if one board was able to be temporarily run-time assigned as master and the other(s) as slave, then the results would be more predictable. However, I'll turn my attention now to trying to programmatically interface to a tcmenu remote interface.