
You might not be able to see much in the above photo, but I'm connecting the comms outputs of one BMU to its own comms input, and connecting the RS485 receiver across all that.
The software is configured to cause a "real time" interrupt every quarter of a second. That interrupt routine does some futzing with a semaphore to see if it is already echoed, and if not, gets the received character, adds one, and sends that character.
So every quarter of a second, the software sends a character and receives it at the same time, adds one to it, and stores it in RAM for the next interrupt.
My first attempt was to merely echo the character as soon as it is received, but that emits 960 characters per second, and TeraTerm can't keep up. I could not tell if the mess on the screen that resulted was because TeraTerm is only echoing every umpteenth character, or because the software wasn't working. It was impressively fast, going through the whole 256 byte "character set" almost 4 times per second, with many beeps and cursor movements thrown in.
With the quarter second interrupt, things are much more civilised, and I was able to see the whole upper and lower case alphabet come out in order, then it goes quiet at around the 0x80 character (TeraTerm is written by a Japanese, and although I've set the language to English several times, it doesn't seem to save (or believe?) the change, and it goes into this mode where characters over 0x7F are treated as some sort of unicode character (I think). I also saw cursor movements, perhaps as a result of an escape sequence.
So basically, it's working fine. This was running the software at 4 MHz; we calculate that there is just barely enough time for one received and one transmit interrupt (let alone a timer overflow interrupt) in the 104 us of one communications bit period.
Oh, as I write this, I've just thought of a nasty flaw in our timing arguments. I won't bother the forum with it here (and embarrass myself at the same time).