RS-485 from Windows

"Meindert Sprang" schreef in bericht news:3f01337c$ snipped-for-privacy@news.nb.nu...

people

I

to

talking

Hmm. Probably a silly idea, but could you calculate the time required to send out all+1 characters and setup a timer event that turns off the RTS ?

-- Thanks, Frank Bemelman (remove 'x' & .invalid when sending email)

I believe ClearCommError has a field that tells you how many chars are pending.

as

code

application

After browsing the net, this is not a silly idea. I think it is the only way to go on application level. The only trick is to get an idea of the timing error of this method. My experience with timer events in windows are not that optimistic.... Thanks for the suggestion.

Meindert

Check out the fRtsControl field of the DCB structure. It can be set to RTS_CONTROL_TOGGLE.

Regards, Karl Olsen

Hi, When you call a GetCommState(), the PC reset (or set, I don't remember) the control signals...

Yvan

********************************* YBDesign *********************************

Meindert Sprang a écrit dans le message :

3f01337c$ snipped-for-privacy@news.nb.nu...

people

I

to

talking

Thanks for all the tips. It seems that setting RTS_CONTROL_TOGGLE in the fRtsControl field of the DCB structure is the way to go.

Meindert

"Meindert Sprang" schreef in bericht news:3f015ceb$ snipped-for-privacy@news.nb.nu...

There appears to be a problem with this, under certain versions of windows:

-- Thanks, Frank Bemelman (remove 'x' & .invalid when sending email)

I know, but I'm using Win2K.

Meindert

If you've got to control the RTS line manually from your app, you got ripped. The only practical way to handle this is to let hardware do it. Any decent RS-485 will take care of it for you.

Perhaps. The people I've talked to who tried to wait for the last stop bit to get onto the wire then toggle RTS in SW never got it to work reliably [I've only tried it under Linux, and I gave up and bought a board that did it in hardware].

Yes. You use a proper RS-485 board.

--
Grant Edwards                   grante             Yow!  ... or were you
                                  at               driving the PONTIAC that
                               visi.com            HONKED at me in MIAMI last
                                                   Tuesday?

I disagree. Software is arguably the correct way to do this. How would hardware know my requirements?

I've seen RS232-485 converters with auto-RTS, but I've yet to see a PCI/ISA board with it. It's assumed that software has control. (That's not to say they don't exist; just never seen one.)

I've had no problem with "getting it to work reliably" under software control - albeit mainly in an embedded environment where I had good control of timers. Windows is indeed another animal - but I've had such cards working reliably under DOS using my listen workaround (see other post).

Steve

I tried the trick with RTS_CONTROL_TOGGLE in the fRTSControl field of the DCB and it works perfectly.

Meindert

I've been doing RS-485 for 15+ years, and the requirement has always been the same: assert RTS (enable line drivers) when transmitting.

The boards are using crappy UARTs. Among others, Exar 16850 UARTs do auto-RTS. Any decent multi-port serial board should handle auto-RTS in hardware.

In an embedded environment it's simple. Under Window/Unix, it's not.

The echo feature may not be available -- some boards will do it, some won't.

--
Grant Edwards                   grante             Yow!  I know how to get the
                                  at               hostesses released! Give
                               visi.com            them their own television
                                                   series!

The last board I used had a pair of transceivers (75176-type) to allow fdx. Non-typical, I guess.

Sure. (Of course a single 75176 [hdx] can also be left receiver-enabled while tx'ing.)

Steve

Not necessarily. If you purchase a card where the manufacturer tied the RE\ and the DE signals together to save an IO pin on the UART, you cannot send and receive at the same time.

Meindert

Paul is 100% correct.

With our 16550 UART we ended up programming a PIC onboard the unit with a one-shot timer that would fire another serial interrupt past the time when the FIFO was empty, and then hacked up the linux serial interrupt and code to trigger and understand this oneshot.

If you're doing your own board design and are using RTS control, try and use a more capable UART.

--
Alex Pavloff - remove BLAH to email
Software Engineer, Eason Technology

[...]

Been there, done similar things (e.g. add an extra byte to the end of the message and shut off RTS when _that_ tx interrupt happens), and wasted a lot of hours...

Definitely.

--
Grant Edwards                   grante             Yow!  .. I'm IMAGINING a
                                  at               sensuous GIRAFFE, CAVORTING
                               visi.com            in the BACK ROOM of a
                                                   KOSHER DELI --

This can be a minor problem if you want really fast turnaround between transmit and receive. Most modern UARTS and OS's use the FIFOs on the UART chip. If the FIFO is active, the UART does not provide an interrupt unless:

1. the FIFO has reached the trigger level,
2. Several character times have gone by with no new input chararcter.

The latter condition means that your OS may not know of the end of the transmit until several character times after the last character is transmitted (and received ) by the sender. As a practical matter it means that you may have to wait for several character times before responding to an incoming message.

Mark Borgerson

For those who are not familiar with this technique, this should work quite well with protocols with distinct frame delimiters, such as SOH, STX and ETX, but it definitely does not work with protocols like Modbus.

When the extra character is 0xFF (for no or odd parity) or 0xFE (for even parity), only the start bit (and the first data bit with 0xFE) is in the "0" state and the line then goes to the "1" state, where it will remain through the (parity and) stop bits and continuing as the idle condition.

If the disabling of the transmitter is delayed by one (or two) bit times, the transmitter has actively driven the line to the "1" state (and charged the line capacitance) when the transmitter goes tri-state. However, if the transmitter is switched off during the start bit ("0"), the passive pull-up resistors have to pull the line to the idle ("1") state.

Paul

"Meindert Sprang" wrote in news:3f01337c$ snipped-for-privacy@news.nb.nu:

If you use blocking mode, this doesn't happen (the WriteFile doesn't exit until all the data has been sent. You don't have any real way of knowing when the RTS will be cleared in this case, only that it is cleared after transmit. Since I had control of both ends, the protocol specified 16 character times of dead space before a response, and I never ran into a conflict. If you don't have control of the other end, though, this might not work.

Blocking mode is sometimes frowned upon in Windows programming (it eats CPU cycles). I put the code in a thread, so my program didn't have any real problems though. The extra CPU cycles were worth it for the much simplified programming. If you try that route, you'll want to look into the SetCommTimeouts to make sure the functions unblock and return in the case of non-response.

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----

The #1 Newsgroup Service in the World! >100,000 Newsgroups

---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---