On Monday, October 17, 2016, Kurt McCullum <kurt.mccul...@att.net> wrote:
> The only time I've seen it go over 64 was when stepping through the T-Word
> code and watching the buffer byte while sending a track (128 bytes +
> header) from sardine.But I may have been watching the wrong byte in memory.
> As far as the 64 byte limit, I had a heck of a time getting that to work
> properly with the Android device. With Windows, the XON/XOFF works pretty
> well. I ended up sending 8 byte chunks and then checking for a flow control
> byte. A pain, but I think I have the timing right.
Well android is Linux so that figures.
A serial port is byte by byte transfer. But unix treats port as a buffered
stream where data is read/written in chunks. So I suspect the low level
receive buffering and the xoff is not processed soon enough to stop
transmission before the m100's 64 byte buffer fills up.
Maybe if the high water mark were tunable to a lower value or the rx buffer
Or serious surgery on the Linux serial port driver :-).
I think your approach of making small writes or per char delays is probably
the only way to go with Linux short of the hardware flow control I did in
HTERM. Which of course doesn't do anything for BASIC or TEXT serial I/O.
I had to do something similar in TBACK with per character delays.