Looking for 9 bit RS485 solutions

On Wed, 24 Oct 2007 20:02:41 -0400, CBFalconer <cbfalconer@yahoo.com>
wrote:

>james.ro123@yahoo.com wrote:
>> james.ro...@yahoo.com wrote:
>> ...
>>> Anyone know of any 9bit 485 adapters, converters, etc.?  My strong
>>> preference is a USB/Ethernet to 9 bit 485 adapter.  Second
>>> preference would be an internal PCI adapter.  One more thing--
>>> we need to set the baud rate to 187.5 kbaud (187500 baud).  An
>>> RS232 to 9 bit 485 (if one exists) would be OK too.
>> 
>> I'd like to thank everyone for their input!  It looks like I'm
>> giving up on USB to 9 bit 485 adapters.  Does anyone know of any
>> USB to 8 bit 485 adapters that will allow me to play the mark/
>> space parity game to emulate the 9th bit (allows mark/space
>> parity & must put byte with parity error in it's buffer)?  Must
>> work at the "odd" baud rate of 187500 baud.  I contacted a few
>> vendors and so far, no luck finding one that does both, but I'm
>> still looking!  :)
>
>Why are you giving up?  There is no problem interfacing any serial
>line with RS485 (which is purely a hardware specification).  Your
>only problem would be to find a suitable UART to create and read
>the serial signal.  All you are looking for is a UART that can
>generate 9 bit signals (plus start/stop bits).  Then you need RS485
>line drivers, in place of RS232 line drivers, all of which are
>available.  If you really want to drive the whole thing from USB
>(why) look for USB driven UARTs.

I very much doubt that this could be done with some USB device due to
the unpredictable delays.

First of all, the USB/serial converters are these days quite
integrated products (no separate standard, well documented UARTs), so
getting sufficient information to effectively program it might be a
problem.

After setting the Mark parity for sending the address byte, you may
(or may not) have to wait that the address byte actually has been
shifted out from the Tx shift register, before setting the UART to
space parity. When this has successfully been done, then you can think
about transmitting the actual data bytes. If you play on the safe
side, the delay between the address and data bytes might be too large
for the other end.

Unless the UART has some kind of automatic data direction control, you
have to wait, until the last byte has _actually_ been shifted out of
the TX shift register, before turning of the transmitter. If you turn
off the RS-485 transceiver chip e.g. with the RTS line when the last
byte is loaded into the shift register, it is quite likely, that the
most significant bits of the last byte are cut off and the bus floats
to Mark ("1") condition due to the "fail-safe" termination.

Even if you have some automatic data direction handling, the UART must
be configured to odd/even parity after the last request byte was sent,
but prior to receiving the response from the slave. If the slave
responds immediately, before the parity has correctly been set up, the
parity error info may be lost. 

The same problem applies also if your system is the slave. While the
slave can delay the response to properly set up the parity settings,
it must be able to quickly receive the next request from the master,
unless some minimum delay (say 10-100 ms) must elapse, before sending
the next response.

Even if you get the parity settings correct, I very much doubt that
any standard USB/serial converter would actually send the parity error
bit synchronously within the same USB frame as the actual data bits.
Most likely you would get a separate frame telling that a parity,
overrun etc. error occurred during the reading of some of the last few
bytes received, but it might be impossible to know, which byte had the
parity error.

It is quite unlikely that you could put any standard USB/serial
converter for this kind of operation even after replacing the crystal
(which might not be an option, if both the USB and serial clock is
derived from the same crystal). Polling the UART status bits over the
USB will cause quite unpredictable delays.

Implementing that kind of protocol with an ordinary ISA or PCI card
under MS-DOS should not be hard, if you use busy loops to poll the
various UART status bits. With multitaskin operating systems, such as
Windows and Linux, there should be hardware support for automatic data
direction control, but fiddling the parity bits should be doable with
any UART, at least if you disable the TX and RX FIFOs.
---
One possible source for 9 bit RS-485 converters might be manufacturers
of development equipment for 8051, 68360 etc. systems that use such
transfer formats.
 
Paul
    

On Oct 25, 2:36 am, Paul Keinanen <keina...@sci.fi> wrote:

...

> Implementing that kind of protocol with an ordinary ISA or PCI card
> under MS-DOS should not be hard, if you use busy loops to poll the
> various UART status bits. With multitaskin operating systems, such as
> Windows and Linux, there should be hardware support for automatic data
> direction control, but fiddling the parity bits should be doable with
> any UART, at least if you disable the TX and RX FIFOs.
> ---
> One possible source for 9 bit RS-485 converters might be manufacturers
> of development equipment for 8051, 68360 etc. systems that use such
> transfer formats.
>
> Paul

Paul,

Very good--that pretty much sums it up!  Unfortunately, it appears
some have lost site of my original post.  I'm really looking for a
store bought solution--no hw mods, fw development, etc.  We can do
that here, but it costs $$ (manpower).  But, as it stands now, if this
PCI card that's under eval doesn't pan out (we didn't receive any
documentation on how to talk to its driver), we'll probably convert
one of our devices that talks this protocol into a test tool.  It'll
require firmware, custom cables, etc. though.  :(

Thanks for clearing things up for people,


Jim

james.ro123@yahoo.com wrote:
> Very good--that pretty much sums it up!  Unfortunately, it appears
> some have lost site of my original post.  I'm really looking for a
> store bought solution--no hw mods, fw development, etc.  We can do
> that here, but it costs $$ (manpower).  But, as it stands now, if this
> PCI card that's under eval doesn't pan out (we didn't receive any
> documentation on how to talk to its driver), we'll probably convert
> one of our devices that talks this protocol into a test tool.  It'll
> require firmware, custom cables, etc. though.  :(

I haven't been on these groups much in the last couple of years but if 
you are still interested I have a few products that will cover your 
requirements. The RS-485 ports are fully programmable in terms of word 
size and baud rate etc. These products all use Propeller multi-processor 
chips and emulate hardware devices by dedicating some of it's processors 
for the job. So they are happy to handle any weird formats etc. I use 
them myself for diagnosing serial coms problems, especially RS485 networks.

BTW, these are all early spec sheets but the products are available.

The CE0072 is designed as a super usb-serial isolated convertor and will 
handle any odd baud rates with a simple menu selection.
http://www.cescom.com.au/new/products/CE-0072/CE0072DS.html

The CE0074 iCONSOLE is more of a standalone computer complete with dual 
SD cards.
http://www.cescom.com.au/new/products/CE-0074/CE0074DS.html

Perhaps this is all that is necessary though, it was designed as a 
RS-232 to RS-485 network adaptor.
http://www.cescom.com.au/new/products/CE-0075/CE0075DS.html

*Peter*