If you have RS232 connections, won't you have one for each device ? Whereas with GPIB, you'll (probably) only have one bus. The GPIB bus will arbitrate and avoid both instruments talking at the same time (this might not be true in talk-only mode since there's no target address involved) but it doesn't provide two completely separate channels.
On Sun, Jan 17, 2016 at 1:01 PM, Magnus Danielson < mag...@rubidium.dyndns.org> wrote: > Poul-Henning, > > On 01/17/2016 01:45 PM, Poul-Henning Kamp wrote: > >> -------- >> In message <569b8b2e.5070...@rubidium.dyndns.org>, 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 -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.