Looking USB to RS-232 + RS-422/485 Module ?

On Sat, 12 Aug 2006 14:14:19 -0000, Grant Edwards <grante@visi.com>
wrote:

>On 2006-08-12, Anton Erasmus <nobody@spam.prevent.net> wrote:
>
>> I have separate USB to RS-232 and USB to RS-422. The problem
>> is that depending on which ports the devices are plugged in,
>> or in which sequence the COM port changes.
>
>And you've been told how to fix that.  Didn't it work?  I know
>you can fix that easily under Linux -- all of my USB serial
>ports show up with pre-configured device names no matter what
>order I plug them in.

Yes, I forgot to mention that. I have not tried it yet, and I am sure
it would work. For future reference though, it is always good to find
suppliers of these sort of things. Having two separate units for 2
channels is fine, but if I need more in the future, then I would like
to know I can get them, and from where.

Since you mention it, how does one fix it in Linux ? 

[Snipped]

Regards
  Anton Erasmus

Anton Erasmus wrote:
> Hi,
> 
> I need 2 simple Asyncronous serial ports on a laptop without any
> serial ports. I have found many USB to RS-232 and a few USB to
> RS-422/485 modules, but have not able to find a reasonably priced unit
> that has one RS-232 port and one RS-422/485 port. We are currently
> using a separate USB to RS-232 and USB to RS422/485, but the "COM"
> port changes depending on the sequence in which they are plugged in.
> This is for a test system where the people are fairly clueless, and I
> want something that stays consistant.
> 
> Regards
>   Anton Erasmus

Have a look at the FTDI website (www.ftdichip.com).  They make USB chips 
and a range of ready-made modules.  I don't know if they have one with 
both an RS-232 and an RS-485 interface, but they have a dual-Uart USB 
device (their Uarts support RS-485 directly) so you could quickly make 
one from their evaluation kit and a couple of driver chips.

They also have information about how to get the virtual comms ports 
numbered by USB location rather than randomly.

David Brown wrote:
> Have a look at the FTDI website (www.ftdichip.com).  They make USB chips 
> and a range of ready-made modules.  I don't know if they have one with 
> both an RS-232 and an RS-485 interface, but they have a dual-Uart USB 
> device (their Uarts support RS-485 directly) so you could quickly make 
> one from their evaluation kit and a couple of driver chips.
> 
> They also have information about how to get the virtual comms ports 
> numbered by USB location rather than randomly.

there is a large range of these types of devices including the FTDI 
units at:
http://www.dontronics-shop.com/home.php?cat=313

Don...



-- 
Don McKenzie
E-Mail Contact Page:               http://www.dontronics.com/e-mail.html

Micro,TTL,USB to 1.5" color LCD http://www.dontronics.com/micro-lcd.html
USB,RS232 or TTL to VGA Monitor http://www.dontronics.com/micro-vga.html
World's smallest USB 2 TTL Conv http://www.dontronics.com/micro-usb.html

Rene Tschaggelar wrote:

>> I always use a small dedicated micro to handle the line turn-around in 
>> RS-485 interfaces. When the control micro is locked to the baud rate 
>> it is possible to have a very tight line turn-around which I usually 
>> set to be around 2 bits.
> 
> This means the micro understands the protocol.

No, but it does mean that certain assumptions are being made, primarily 
that when the transmit data stops for two bit times, the line can be 
turned around.

Peter

On Mon, 14 Aug 2006 10:50:33 +1000, Pete <pjetson@yahoo.com> wrote:

>Rene Tschaggelar wrote:
>
>>> I always use a small dedicated micro to handle the line turn-around in 
>>> RS-485 interfaces. When the control micro is locked to the baud rate 
>>> it is possible to have a very tight line turn-around which I usually 
>>> set to be around 2 bits.
>> 
>> This means the micro understands the protocol.
>
>No, but it does mean that certain assumptions are being made, primarily 
>that when the transmit data stops for two bit times, the line can be 
>turned around.

The converter needs to know the bit rate, number of data and stop bits
and also if parity bit is used. In this way, the converter can always
detect the start bit correctly even in a string of characters and thus
also knows when the (last) stop bit is expected. The transmitter can
be turned off immediately after the stop bit(s), but to avoid problems
with propagation delays and badly terminated lines, the transmitter
may be on for an additional 1-2 bit times, in case the start bit of
next character arrives before that.

If the bit rate is known, but not the character length, you must
assume that the last "0" bit detected is a start bit and wait for
about 11 consecutive "1" bits before turning off the transmitter. This
is sufficient for the Modbus protocol which uses a 3.5 character pause
(35-40 bit times) as the end of frame marker, thus, no responses can
arrive before that. However, in protocols with distinct end of message
characters especially with low line speeds and high performance
processors, the slave may respond in much less than a single character
time and relying on the last "0" bit as a worst case start bit will
fail.

However, if only short distance test transmissions e.g. on the lab
bench is required, simply use the RS-485 as a CANbus style wired-OR
configuration. The transmitter is driven active only by the "0"
(dominant) serial bit, but is put into passive tri-state when the "1"
bit or intercharacter idle is to be transmitted, the "fail-safe"
termination will pull the bus into the "1" state. This will however
reduce the noise margin and thus, should not be used with long cables
or in a harsh environment.

Paul

>>> I have separate USB to RS-232 and USB to RS-422. The problem
>>> is that depending on which ports the devices are plugged in,
>>> or in which sequence the COM port changes.

Another one:

http://www.moschip.com/ 

Pete wrote:
> Rene Tschaggelar wrote:
> 
>>> I always use a small dedicated micro to handle the line turn-around 
>>> in RS-485 interfaces. When the control micro is locked to the baud 
>>> rate it is possible to have a very tight line turn-around which I 
>>> usually set to be around 2 bits.
>>
>>
>> This means the micro understands the protocol.
> 
> 
> No, but it does mean that certain assumptions are being made, primarily 
> that when the transmit data stops for two bit times, the line can be 
> turned around.

A Microsoft windows doesn't meet this gapless-
requeirement.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net