COM Port Flow Control setting?

trevor29

Hi, I have a Propellor servo controller(USB) that I am using for an Animatronic project. Im also using VSA as the programming software. Everything works perfectly. But my question is about the Flow Control setting in the com port properties. What should I set it to for optimum speed and performance? "None" "Xon/Xoff" or "Hardware"?

Phil Pilgrim (PhiPi)

I would say NONE. There's nothing in the PSC docs about flow control or hadnshaking.

-Phil

LoopyByteloose

In general, NONE is best if that works properly.

All Flow Control asserts that one of the two communication devices must wait for the other.

Hardware flow control is the most reliable, but takes additional communication wires ... not just an RX and TX.

XON and XOFF may require some modification to buffers to get the flow to work well. I am now looking at code that has the RX buffer assert and XON when it hits 3/4 full. This is to prevent overfilling the RX buffer and loosing incoming data. And for the TX buffer of the same, the scheme desires no buffer. That is so that the XOFF gets sent right away.

This XON/XOFF may or may not work with all setups. But it certainly gives one an idea of the added complexity of software flow control.

Conceptually, flow control works best when the devices are in a Master/Slave relationship. Expectations about who sends and who listens are easier to sort out.

+++++++++++
If you do run into communication problems, it might be wiser to first try to speed up or slow down the baud rate and see if the problem goes away. Sometimes a faster baud rate will get the job done and clear the buffers before they are overrun. Slower baud rates generally resolve problems in long wires degrading the serial information.

Heater.

Generally flow control is required because the receiving end cannot process the incoming data fast enough. Simple as that.


If the incoming data is "bursty", for example messages come in very fast but there is a nice delay between messages, then often buffering will solve the problem without flow control. The Rx buffer just has to be big enough to hold a bust of data. That buffer can be emptied and the data processed before the next burst arrives. One may need bigger buffers to hold bigger bursts or messages. I believe there are serial port objects in the OBEX that allow you to have bigger buffers than the original FullDuplexSerial object.


If you communication protocol is a master/slave arrangement, i.e. send command, wait for reply, send next command... then flow control can be done simply by arranging that the master slows down the rate at which it sends commands and expects responses. There will have to me enough buffering in the receiver to hold each command of course. A slower command rate, even if the baud rate is high, can make things workable.

Sometimes a faster baud rate will get the job done and clear the buffers before they are overrun.

This is totally backwards, if your data is coming in faster than you can handle it increasing the baud rate can only make it worse. Conversely making the baud rate slower will eventual ensure that data cannot physical arrive faster that you can handle it.


I would switch flow control off, seeing as the Propeller serial objects don't support it (or are there ones that do?). Start with a low baud rate that works and then experiment with increasing it.


Be sure the baud rates are set the same in Tx and Rx of course!