Nick_Pyner Thank you for the suggestion. I tried tinkering the baud rate down to 9600 but it didn't seem to change any of the behavior I was seeing.
I had a pretty great breakthrough this morning and I think I have the Nano-->Mega-->Nano serial transmission working with limited latency. (And I might be able to tinker with that a bit to further improve, but I am happy with it right now).
I think the major issue I was running into was that the serial buffer was filling up faster than I could clear it. As a result, the data communication would work for precisely some number of seconds (between 4 seconds and 16 seconds under various code versions, but always the same amount for a given code version) and then it would get more and more sluggish to respond to changes in the potentiometer knob in the Nano1. Or it would be grabbing way too many digits from the buffer and would be spitting out numbers like 454444555445455555 instead of the intended 45.
There also seems to be some practical speed at which serial data seems to arrive intact, but below which it gets jumbled. 250ms is so far as fast as I seem to be able to push it, but I will try to tinker this downwards and see how low it can go. Baud rate didn't seem to affect this number. This limit on sending data and having it be sent intact was pretty surprising and counterintuitive to me. Clearly I don't know much about this stuff, so maybe it makes sense to others... but for now I am including the 250ms delays on sending serial data because it "just works" and I'll continue to test with it in the future and report back if I can deduce anything else.
Here's a simplified version of the timing from board to board which seems to work:
- Nano1 sends a two-digit reading to serial at 250ms intervals
- Mega runs through 10 iterations of Robin2's recvWithEndMarker(); and showNewNumber(); to ensure the buffer is clear, then pauses for 250ms and then sends off the data to serial
- Nano2 runs recvWithEndMarker(); 10 times in 500ms (while doing some other stuff with LEDs in parallel), then runs showNewNumber(); 1 time and uses that data to inform how the LEDs will be updated in the next loop of Nano2.
So far it appears this is close to 100% reliable. I haven't tested it for more than 5 minutes or so, but issues have historically popped up much faster than that, so I am optimistic. My next steps will be to tinker with the number of iterations of recvWithEndMarker(); to see how low I can push it, and the 250ms delay to see how low I can push that as well.