23 Feb
2013
23 Feb
'13
11:10 a.m.
On 02/23/2013 10:01 AM, allison wrote:
Simple solution, SLOW DOWN the data rate until it
works.
Flow control is only needed in systems that cannot handle high rates of
traffic.
On a lot of the older micros hardware flow control was best if available as
the system often was so slow it could not keep up or send xoff in a timely
fashion. Also pre enhanced 16450 usart most only could buffer maybe
1 to 3 chars in the part.
Yes, having slept on it this seems sensible - the transfer rates I'm
getting at 9600 seem to be far worse than I'd expect even with the receiver
having the overhead of a slow BASIC interpreter, suggesting that the link
might be almost saturated with XON/XOFF flow control chars. It still seems
odd that receipt of 19d as the checksum byte trips it up, when 19d at other
times doesn't; I've looked at the Linux sx code now and it doesn't seem to
be doing anything special when it sends the checksum byte that it doesn't
do for other data.
I don't think I can turn off software flow control from RSI basic (the
manual suggests that it's always present), and there seems to be no way of
changing the line speed via the basic environment either - but I think
there is a TPM util (just not included in the TPM 'install' on the RSI
disk) to set the line parameters, so I'll go hunting for that. Hopefully
the RSI interpreter honors whatever the OS has previously set up, rather
than resetting to its own defaults at startup.
Worst-case I suppose I can hack the sx code on the Linux side and introduce
some time-wasting loops so that it doesn't send as fast across the 9600
link, but it'd be nice to avoid having to do that if I can.
cheers
Jules