Poul-Henning,
On 01/17/2016 01:45 PM, Poul-Henning Kamp wrote:
--------
In message <[email protected]>, Magnus Danielson writes:
I think you should develop that line of thought, to detail why it helps
on GPIB and why not on serial.
It's really very simple: RS-232 sends blind, you don't even need to
know if there is a receiver or what it does. If the receiver cannot
keep op, data is simply lost.
GPIB handshakes every byte, so the actions of the receiving end affects
the transmitting end - in particular if the receiver cannot keep up.
OK, you where thinking about the flow-control.
You can have RS-232 wired up to do flow-control (hardware-flow-control),
But the important point is you don't have to do that, all you need
is two wires: GND-GND and TXD->RXD
With GPIB that option does not exist, sender and receiver are always
in lock-step.
Therefore, talk-only mode is a big advantage in terms of decoupling
on RS-232 and makes almost no difference on GPIB.
If we can assume the consumption is fast enough to keep track, yes.
If it's not, flow control for this situation helps the border case
somewhat, but if you are too slow, you are screwed anyway.
In the case that Attila describes, the flow-control helps over the
various borders, especially as scheduling plays tricks with us. Running
virtual applications like that does not help to get a grip of control
over how data is transfered and when. If it where only to get it
straight into an app really talking to the serial ports, sure, but I do
not trust the virtualization to handle it all to well.
Not that hardware flow-control would in itself help much, but anyway.
Regardless, if the TimeLab needs to send commands back to the counter
over the virtualization border, then getting things scheduled properly
in time isn't really guaranteed.
Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
