I have a PC104 SBC that has onboard RS485 ports. I previously wrote standard RS232 comm port routines to talk to devices on the rs485 network by using a 232 > 485 convertor and everything worked great. Now, however, I want to use the onboard 485 ports. I have two questions....
1, my port is a 4 wire, my network is a 2 wire. This is how I converted.
+TX & +RX Tied together, -TX & - RX Tied together. The -TX & -RX hook to A on the Network, and the +TX & + RX hook to B on the network. Is this correct?
In my standard Rs232 Routines, I modified to simply Raise RTS, wait 10 ms, then then the string, wait 10ms, lower RTS. I don't do anything special at all waiting on chars to arrive.
Problem is, none of this works. Any pointers? I assume I can use the standard Serial Port Routines if I turn off All flowcontrol and use the RTS line right?
I find tons of info on the difference in the specs, but not much about writing to the ports.
At least there has to be a jumper / control bit determining which of the incoming data buffers is connected to the UART receiver: you cannot feed it from RS-232 and RS-485 buffers at the same time. The feature is not standard on a PC serial port, it could be using the extra output bits present on
8250 -series interface chips. Go after the hardware documentation / vendor for details.
Although I don't know much about RS85 and I don't know the pinout of the onboard port in RS485 mode, I've had the same problems with ADVANTECH hardware, trying to talk to industrial I/O ADAM modules from a SBC motherboard (in the "embedded" product line), by switching the direction using RTS too (and the RTS toggle mode that sets automatically RTS during a write operation). By calling their technical support they explained me that the RS485 ports on their motherboards don't fully support RS485, especially the automatic detection of receiving data, a functionality required to communicate with most RS485-compliant devices. Then I guess that RTS is unable to switch early enough the line in receive mode, causing incoming data loss. The only solution we found was either to buy an extension card with real RS485 ports, or to use a RS232RS485 adapter like you did.
If your network is (i.e. MUST BE) 2 wire, then yes. :>
Presumably, the 232-485 converter used RTS as a "direction control" (typical). As such, it caused the 485 transceiver to "drive* the network when you were "transmitting" data, etc.
Since you don't explicitly mention *discarding* and/or *checking* the data RECEIVED while transmitting (i.e. a copy of YOUR outgoing data), I assume the 232-485 converter disabled the 485 receiver while "transmitting"...
You've not mentioned the protocol you are using to govern/arbitrate access to the network so there are big issues unstated...
The first 10ms (before Tx) is probably overkill. You just need to wait long enough for the 485 transceiver to "flip" to Tx mode. The *second*
10ms may be too small (unlikely since you haven't complained about data being "clipped"), just right, or too long.
Essentially, you want to wait for the last character to *clear* the transmitter portion of the UART before twiddling RTS. Note that this is usually one (or more!) "character times" (i.e. 10 or 11 times the "bit time") AFTER the last "transmit register empty" interrupt. It depends on the UART being used (how deep the transmit buffer is, etc.) as well as your actual bit rate.
Using a fixed "10 ms" may (does?!) work for your current conditions. But, moving to a slower bit rate, different UART or even changes in the network cabling can cause that fixed delay to become inadequate at some future date.
You want to make sure the last bit of the last character transmitted has cleared the "TxD" pin on the UART *and* had a chance to propagate through the network (cable length and potential reflections if improperly terminated) before turning off the transmitter (via RTS) and relinquishing the wire to other potential masters (transmitting nodes)
Make sure you have terminated the network properly...
Depends on what the 485 ports on your board are wired as. You haven't said if they are the same UARTs that you have been using with 232 (i.e. just some jumpers to handle the 232/485 strapping option) or if they are implemented with different physical devices entirely, etc.
The vendor/documentation should be able to tell you what controls the transmitter ("direction") in the 485 transceiver (i.e. RTS, or some other mechanism). Your protocol choices will also affect how and when you drive the wire -- as well as how you respond to activity
*on* the wire (e.g., resolve contention, etc.)
Your vendor may, also, provide sample routines describing how they
*suggest* that you use the ports (though they may be highly simplified and/or not optimized nor applicable to your particular protocol). But, a good place to *start*!
N.B. Incoming mail is not accepted at this email address.
This is why the chief engineer had someone invent oscilloscopes!
10mSec seems like a long delay after transmission. What is the baud rate? You should normally delay only about one character time after the end of a transmission to switch to receive. This is especially true if your device is a system master. At faster baud rates, some devices my have completed their response in 10mSec.
Get a scope and make sure your data is actually being transmitted. Then see if you can find any responses.
Then verify the settings with the oscilloscope! ;-)
Got it, Actually after writing this email I broke out the storage scope and checked it. Since the RS485 is Com4, IRQ 10 the IRQ Vector was set wrong. Once I fixed that, I simply use the RTS before sending data and she worked great.
I just has so many new items I was testing so I had to narrow the problem down and the trusty Oscope let me know where the problem was. Again, Thanks for the help.
Yes, this was an Advantech board. I fixed it by doing the following:
1st - fixed the IRQ Vector problem - I was using the wrong value for the non-standard port.
2nd - Using standard RS232 Comm Routines however I turned off all the port options (required for modems)
3rd - I simply switch the RTS before sending data, then switch it back immediately after the send buffer is clear.
I'm communicating okay at 38,400 using Modbus RTU (4 wire to 2 wire setup). I never used 485 before beside with an 232 to 485 adapter so I wasn't sure what to expect.