Thanks for your suggestion.
The 8 bit Arduino microcontrollers based on the AVR chips only have 64 bytes of incoming serial buffer. It's certainly not much, but it's more than enough for human typed text on a terminal. Even if the keystrokes processing on the Arduino side would be really slow, it's highly unlikely that a human would type text at such a fast pace as to completely fill the 64 byte buffer.
So the problem I have is not really on this scenario, but when attempting to send files over serial. In such case, you are right that slowing down the pace of transmitted data solves the issue. My files consist on lines of text terminated with CR characters, these lines contain commands that the Arduino parses and executes.
Specifying a delay on ColdTerminal based on the 0A (hex) character prevents loss of data due to Arduino serial buffer to overflow. This is a great feature on ColdTerminal by the way.
However, this of course slows down transmission, and its reliability may be inconsistent in cases where the Arduino takes longer to process the incoming data in general, or to execute a particularly difficult command in the text file. It's kind of a tradeoff between speed and reliability.
Ideally, a true flow control procedure would be a lot more desirable because it would be as fast as the Arduino allows, and fully reliable.
So I tried to implement Xon/Xoff flow control on the Arduino side, and this certainly works on the CoolTerm side by preventing keystrokes.
But it doesn't seem to do anything to stop data transmission from a file. I'm unsure if this is a CoolTerm bug or just that the local outgoing serial buffer (in the computer) is filled too fast for the application to actually detect any Xoff on time (?).
I think it's not the latter because even with transmission delays in place, the application does not stop file transmission. The Xoff characters are clearly received and reported on the ColdTerm "Hex View" screen but they don't seem to do anything to stop file transmission?
Any ideas or suggestions ?
Thanks
*** EDIT ***
Ok, I found that ColdTerm DOES actually stop transmission when receiving an Xoff character. So it's NOT a bug.
However, for the whole thing to work, some transmission delay still needs to be specified in order to give ColdTerm some time to receive the XOFF character before it's too late. Otherwise, the computer output buffer seems to be filled too quickly and with too many characters before the XOFF action actually takes place.
I also optimised my code on the Arduino so that incoming commands from files are quickly stored on a temporary buffer, before the command is actually processed (as opposed to parsing incoming commands on the fly as more characters were received). This provides a consistent time from receiving a bunch of characters to the issuance of the Xoff character, which is totally independent of the command processing time, thus allowing for a much smaller 'delay' specified on ColdTerm and faster overall transmission.
So this seems to work fine for me now.
Thanks again