🚀 go-pugleaf

> The way to enable the TX section of RS485 transceiver is
> drive the RTS signal, so I used the SetCommState API setting
> the fRtsControl field of DCB to RTS_TOGGLE value.

> This approach works fine in any PC I tried from Windows95
> to WinXP.

IMHO, you've only been lucky.

At first, RTS_CONTROL_TOGGLE is not supported under Win95, Win98 
and WinMe as stated in MSDN: 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/dcb_str.asp.

Secondly, as far as I know, there's no way to control the real 
end of transmission under WindowsNT/2000/XP. In the old time of 
DOS, we could read the status of the shift register. That could 
also be done under Win95/98 although not a clean solution. 
Nevertheless, through Windows API, we can check the status 
(empty or not) of the trasmission buffer that is not necessary 
the serial trasmission status (finished or not).

> I have a problem on a DELL notebook with WinXP SP2 and 
> CENTRINO processor.
> My application sends a frame but RTS signal remains high for 
> 15 ms.
> instead of 1-2 ms.!!!!!

That's strange, anyway. RTS goes down sooner than the end of 
transmission, usually. Maybe a particular serial driver is 
installed there.

> I tried to install the trial versione of BDS2006 and recompile 
> my
> project and...suprise...it works well and RTS signal goes down
> in 1 ms.!

I don't know about this.

> Is there someone can explain me this behaviour?

Not the last one. Instead, about how to handle properly a 485 
transmission under WinXP, well, I've been looking for a good 
solution for years... no one found so far.

> How can I work around this bug using C++Builder6?

A good suggestion? Use a "smart" 232/485 converter. No need to 
drive the RTS signal any more.

HTH,

Stefano. 

Hi,

I think that I agree. Even using the TX uffer empty is of no use because 
it just indicates that the last data has been tranfered to the USRT. As 
far as I know, there is no reliable way to tell just when the last bit 
has left the UART out into cyber space. Even calculating the how long it 
would take to transmit n bits at the current baud rate, parity and stop 
bit settings is unreliable. If you are driving RS232 into a radio its 
not much of a problem to add a little time but with RS485, the 
turnaround time is critical and you must switch to receive after the 
last bit is transmitted and before the external device responds.

Tom Woodrow

SF wrote:

>>The way to enable the TX section of RS485 transceiver is
>>drive the RTS signal, so I used the SetCommState API setting
>>the fRtsControl field of DCB to RTS_TOGGLE value.
> 
> 
>>This approach works fine in any PC I tried from Windows95
>>to WinXP.
> 
> 
> IMHO, you've only been lucky.
> 
> At first, RTS_CONTROL_TOGGLE is not supported under Win95, Win98 
> and WinMe as stated in MSDN: 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/dcb_str.asp.
> 
> Secondly, as far as I know, there's no way to control the real 
> end of transmission under WindowsNT/2000/XP. In the old time of 
> DOS, we could read the status of the shift register. That could 
> also be done under Win95/98 although not a clean solution. 
> Nevertheless, through Windows API, we can check the status 
> (empty or not) of the trasmission buffer that is not necessary 
> the serial trasmission status (finished or not).
> 
> 
>>I have a problem on a DELL notebook with WinXP SP2 and 
>>CENTRINO processor.
>>My application sends a frame but RTS signal remains high for 
>>15 ms.
>>instead of 1-2 ms.!!!!!
> 
> 
> That's strange, anyway. RTS goes down sooner than the end of 
> transmission, usually. Maybe a particular serial driver is 
> installed there.
> 
> 
>>I tried to install the trial versione of BDS2006 and recompile 
>>my
>>project and...suprise...it works well and RTS signal goes down
>>in 1 ms.!
> 
> 
> I don't know about this.
> 
> 
>>Is there someone can explain me this behaviour?
> 
> 
> Not the last one. Instead, about how to handle properly a 485 
> transmission under WinXP, well, I've been looking for a good 
> solution for years... no one found so far.
> 
> 
>>How can I work around this bug using C++Builder6?
> 
> 
> A good suggestion? Use a "smart" 232/485 converter. No need to 
> drive the RTS signal any more.
> 
> HTH,
> 
> Stefano. 
> 
>