RS232 Buffer Question

[rovtech]

I do believe what you say and have a lot of respect for everyone that replies on this site. I also try what is suggested.
However in this case you are talking about a different rs485 driver. That one has tri-state Rx & Tx so a pullup will work. The DS3695 RO output (to Rx, I originally had Tx which caused me to make further errors) will sink 16 mA so it is not wise to try and pull it high (wrong, see note below). It also will source 400uA so it essentially has a pullup and is not open collector/drain (wrong).
I connected 4.7k from Rx (I originally had Tx) to +5v for the pullup as you suggested. The 120 ohm termination resistors are already installed (yes but the pullup was not installed for these pictures).
I then connected a bias network to the 120 ohm termination resistor (60 ohms total because of the one at the other end). I actually calculated the values for 120 ohms but despite that the bias worked reliably. So 60 ohms across the bus, 1600 ohms to +5v on one side of the bus, and 510 ohms to ground from the other side of the bus to give a differential voltage of 0.14v but should be 0.2v or higher.

Connected one way Tx is low between transmissions as seen here. The pullup does nothing (wrong, it actually would look like the next picture. Note the negative pulses in trace 3. This is what the pullup is all about).



Switching the connections on the bus and Tx is high between transmissions as seen here.



I have a 1ms delay between sending from the master (middle trace) and receiving from the slave (bottom trace). The last character sent is 0x55 (01010101) and the first character returned is 0xaa (10101010). Both have a high start bit and a low stop bit so they are 1010101010 and 1101010100.
These are the last of ten characters sent and the first of ten characters replied. The DS3695 appears to invert the data.

I next tried removing ERRORS from #use rs232() with the bias one way, then the other , then with no bias. The pullup was on Tx for all these tests (correct). The communications failed so ERRORS is necessary for this setup.

As Ttelmah said:
"The reason that ERRORS affects things, is that this copies the UART status into the variable RS232_ERRORS. Since this can't happen till after the byte transfer has completed, adding 'ERRORS' makes the software wait until the transmission has completed."

and that answered my original request for help. I don't have a problem anymore but I'm sure these exchanges will help others.
Thanks everyone.

NOTE: There are errors in the above that are pointed out in later posts. The worst error is that the first 'scope picture does not have the pullup resistor in place and trace 3 shows noise pulses on the RO pin.
The 'scope pictures are useful though as the second picture shows what the pullup resistor would do, as well as both illustrating what bus biasing does. I have tried to edit the above with notes but not changing it.

[rovtech]

I will have another try at the picture of my console and robotic arm. An arm is easy, making it waterproof not so much.
The arm moves left and right 180 degrees, and up and down 270 degrees. The Gripper pod moves 180 degrees and rotates about 300 degrees. The gripper opens and closes through the right-angled gears and has two white LED lights and a camera. It also has parallel laser beams to judge the size of objects by placing two dots 2" apart on them. The motor shafts are sealed by O-rings. Each section has its own PIC and is controlled through 4 #28 wires carrying power and I2C. Two more wires carry the video. Polyflo tubing and fittings seal the wires from water pressure.
Software limits prevent the arm from running into the ROV. The arm folds when not in use.
It is seen here running on a test port located in the back of the Console (the black cable). It will eventually get the same commands by rs485 to the ROV and from the main ROV PIC (there are 4 of them at present) by I2c. Distributed control and power.
Don't use an Apple III joystick as I have. It needed current sources because the pots are not connected at one end. I have some really nice ones from China to replace it, the one bottom right. It controls the ROV through dives and turns. The side motors, their speed and direction, and the rudder and elevator are all software coupled. A hard turn will reverse one side motor and speed up the other. A hard climb or dive will rotate the side motors along with elevator movement. It works far better than I thought it would and is very manoeuvrable.
I am happy to help anyone with similar projects.

[PCM programmer]

The ds3695 absolutely has a tri-stateable RO output pin. Look at the
truth table on page 6 of the data sheet. If you take \RE high, then RO
goes to a Hi-Z (tri-state) state. See the red circled area below:



And you can certainly put a 10k pull-up to Vdd on the RO output pin of
the ds3695. It won't hurt it. The most current a 10K pull-up can source
is 0.5 ma (with Vdd = +5v). The ds3695 can safely sink way more than
that. There's no problem. Here is the ds3695 data sheet:
http://www.ti.com/lit/ds/symlink/ds3695.pdf

[Ttelmah]

and just to add. The circuit posted has the transmit enable and receive enable wired together. So when the unit is transmitting, the receive buffer has it's output floating.
I think you are forgetting that the UART will be 'listening', even when you are transmitting. The UART is full duplex, even if the link being used is only half duplex.

It's perfectly possible to work the other way, and never disable the receive buffer. If you do this, no pull-up is needed, and the circuit will receive everything that is sent (which can be used as a diagnostic to test what is actually going onto the bus). However it then means the receive code needs to be able to detect and handle this.

[rovtech]

Thanks PCM programmer. I stand corrected. My post was full of typos and errors.
However I did put the pullup on RO (pin 1) that connects to Rx (Tx was a typo). When it did not change the need for ERRORS in #use rs232() I took it off so the first 'scope picture using bus biasing actually shows the noise pulses every time ENABLE goes low (trace 3).
It was right in front of me but I was concentrating on the bus with zero volts being a non valid condition and completely missed the point of Rx floating when transmitting. Even my notes scribbled on my data sheet refer to this but it was not where my mind was.
Thanks Ttelmah, you are correct that I was not thinking of the UART listening when transmitting and the feedthrough pulses when ENABLE goes low can be seen in my scope pictures (trace 3). RO is low with positive pulses. The pullup holds RO high and there are no pulses. It looks like the second 'scope picture of bias experiments.
I have edited that post to correct it but without removing my errors.
I finally understand.

[Ttelmah]

The compiler actually disables the enable half way through the stop bit. If the pin is floating, this gives the pulses....

Official 'penny drops' moment.