Hi all,

This might not be the right group to ask, but I suspect there must be people
outhere who have dealt with this:

I have an RS485 board in my Win2K machine, which uses the RTS signal to
change the direction of the RS-485 tranceiver.

With EscapeCommFunction() I can change the state of the RTS signal but, as I
espected, this function almost works immediately. Thus, the following code
will not work:

EscapeCommFunction(hComm,SETRTS);
WriteFile(hComm,.......)
EscapeCommFunction(hComm,CLSRTS);

The last call to EscapeCommFunction() will put the RS485 transceiver in
receive before the data is really sent. Is there a way for an application to
check wether all data has been sent, from within windows?

This must be a known issue since the existense of for instance PC's talking
Modbus....

Meindert

"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> schreef in bericht
news:3f01337c$1@news.nb.nu...

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.

"Frank Bemelman" <bemelmanx@euronet.nl.invalid> wrote in message
news:3f014c59$0$28898$1b62eedf@news.euronet.nl...

"Frank Bemelman" <bemelmanx@euronet.nl.invalid> wrote in message
news:3f014c59$0$28898$1b62eedf@news.euronet.nl...
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

Meindert Sprang wrote:

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
http://www.ybdesign.fr
*********************************



Meindert Sprang <mhsprang@NOcustomSPAMware.nl> a écrit dans le message :
3f01337c$1@news.nb.nu...

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" <mhsprang@NOcustomSPAMware.nl> schreef in bericht
news:3f015ceb$1@news.nb.nu...
There appears to be a problem with this, under certain versions
of windows:

http://support.microsoft.com/support.../Q140/0/30.asp


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

"Frank Bemelman" <bemelmanx@euronet.nl.invalid> wrote in message
news:3f0165d5$0$28903$1b62eedf@news.euronet.nl...
I know, but I'm using Win2K.

Meindert

In article <3f01337c$1@news.nb.nu>, Meindert Sprang wrote:

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?

"Grant Edwards" <grante@visi.com> wrote in message
news:3f019c25$0$634$a1866201@newsreader.visi.com.. .
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
http://www.fivetrees.com
http://www.sfdesign.co.uk

"Grant Edwards" <grante@visi.com> wrote in message
news:3f019c25$0$634$a1866201@newsreader.visi.com.. .
DCB and it works perfectly.

Meindert

In article <3f01337c$1@news.nb.nu>, mhsprang@NOcustomSPAMware.nl says...
Would setting commdcb.fRtsControl = RTS_CONTROL_TOGGLE;

work in Win2K? Microsoft seems to acknowledge that it doesn't work
in 95/98/ME.

http://msdn.microsoft.com/library/default.asp?
url=/library/en/us/devio/base/dcb_str.asp

(Just do a Google search on RTS_CONTROL_TOGGLE.)

IIRC, I was able to get 485 comms working using that setting
in an earlier XP application usin C++ Builder.

Most of the newer UARTS can be programmed to generate an interrupt
when both the FIFO and transmit shift register are empty (Although
I do recall some discussion about whether the interrupt occurred
before the end of the last stop bit). One would hope that
MS has taken advantage of that interrupt in the serial driver
of the latest windows versions.

Mark Borgerson

In article <bds7ru$5$1$8300dec7@news.demon.co.uk>, steve at fivetrees wrote:
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!

"Grant Edwards" <grante@visi.com> wrote in message
news:3f01de27$0$626$a1866201@newsreader.visi.com.. .
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
http://www.fivetrees.com
http://www.sfdesign.co.uk

"Alexander Baranov" <alexanderbaranov@hotmail.com> wrote in message
news:c1161b98.0307011008.5e669a54@posting.google.c om...
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

On Tue, 01 Jul 2003 22:07:02 +0300, Paul Keinanen <keinanen@sci.fi>
wrote:

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

In article <8ru3gvkk8r2grhvicsm1m6crpdnfc0df16@4ax.com>, Alex Pavloff wrote:

[...]

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 --

In article <3f01abcb_7@corp.newsgroups.com>, nospam@nospam.net says...
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

On 01 Jul 2003 21:45:25 GMT, grante@visi.com (Grant Edwards) wrote:


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