The fact that you're polling the pin for serial data in itself is the cause for the behaviour mentioned. SerOut2 is a bit-banging routine as is Serin2. Since your motor controller is echoing back all data sent to it, with some processing delay of its own, I suspect, you are not reading back fast enough to catch the data stream with serin2. Another possibility is that the data has already overflowed and the OERR flag is cleared only when you invoke Serin2.
I can suggest you try a dummy Serin2 after each Serout2 statement. I am not sure if this will help in any way. This would keep the OERR clear if it is the one causing the problems. Other than this, I think, the only way out is to have the hardware USART interrupt to tackle this kind of a situation.
Bookmarks