Searching \ for '[EE] Multichannel USB UARTs' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=multichannel+usb
Search entire site for: 'Multichannel USB UARTs'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Multichannel USB UARTs'
2006\04\24@051358 by Simon.Nield

flavicon
face
Does anyone know of any multichannel USB UARTs, or a USB microcontroller
appnote for the same?

I need a bunch of 115200 RS485 connections to a PC via USB. At least 8
channels, ten would be nice.

I have looked at Oxford Semiconductors' Quad USB UART, but it requires
external RAM, and EEPROM, and does not have support for controlling the
output enable of an RS485 driver.

FTDI do a dual UART (http://www.ftdichip.com/Products/FT2232C.htm) which
looks ok, but would mean I need to use a two usb hub chips to get the
number of channels I am after, and that seems a bit ungainly.

I remembered that Bob Ammerman had writted an octal UAR(no T):
www.piclist.com/techref/microchip/16F84-rs232-8ch-ba.htm
and was wondering about implementing an enhanced version (with the
transmit side added) in one of the 18F series USB capable PICs. Microchip
do have an app note covering the windows / USB side of it
(http://ww1.microchip.com/downloads/en/AppNotes/00956b.pdf), but it seems
a bit of a leap from 9600 to 115200, when the clock rate has only
increased by a factor of two and a bit.


Any of you guys got any suggestions?

Simon

2006\04\24@053957 by Alan B. Pearce

face picon face
>FTDI do a dual UART (http://www.ftdichip.com/Products/FT2232C.htm)
>which looks ok, but would mean I need to use a two usb hub chips
>to get the number of channels I am after, and that seems a bit ungainly.

Don't forget that there is an I2C/SPI/Bit Bang interface on this chip as
well, so you could hook a number of other chips on there to expand your
channels. Would seem like a UBICOM SX series chip with soft peripherals
might be a starter for multiple UARTS.

Never used the chip myself, so don't know if the other interface replaces a
UART ...

2006\04\24@062140 by Mike Harrison

flavicon
face
On Mon, 24 Apr 2006 10:16:16 +0100, you wrote:

{Quote hidden}

I'd look at using a fast USB interface to an external multiplexer type arrangement- maybe an FT245
with a CPLD or fast microcontroller to split the data into the required number of channels.
Or maybe a USB microcontroller,  with a CPLD to implement the uarts if necessary.
 

2006\04\24@092132 by David VanHorn

picon face
InsideOut Networks does a thing called an edgeport, available in 232 or 485
http://www.digi.com/products/usb/edgeport.jsp

Up to 16 ports on a single connection.
I use them a lot.

--
Feel the power of the dark side!  Atmel AVR

2006\04\24@110250 by William Chops Westfield

face picon face
>> I need a bunch of 115200 RS485 connections to a PC via USB.
>> At least 8 channels, ten would be nice.
>>
Ten of 115200bps is a pretty non-trivial task.  By my calculations,
it gives you about 4 microseconds per character to do... everything.

FIFOs in high speed uarts are usually offered as a solution, but
they're not a big help.  To get this sort of performance in real
world devices one starts to look for uarts with DMA capability,
hopes for something like PPP to clump the data, and struggles with
the latency vs throughput issues that show up with DMA...

BillW

2006\04\24@111009 by Simon.Nield

flavicon
face
> InsideOut Networks does a thing called an edgeport, available in 232 or
485
> http://www.digi.com/products/usb/edgeport.jsp

any idea what devices they use inside?

2006\04\24@113626 by David VanHorn

picon face
On 4/24/06, spam_OUTSimon.NieldTakeThisOuTspamquantel.com <.....Simon.NieldKILLspamspam@spam@quantel.com> wrote:
>
> > InsideOut Networks does a thing called an edgeport, available in 232 or
> 485
> > http://www.digi.com/products/usb/edgeport.jsp
>
> any idea what devices they use inside?


It's a fair bit of complexity, About a 4 x 6 board, of about average
density.  I had a look inside once, but didn't see anything I recognized.

I've done multiple serial ports as a multiplexer, in the AVR.
An 8 MHz 8515 handling 8 channels at 4800 full duplex, plus link channel at
115200, plus a couple of "virtual" internal channels.  In that
implementation I used MAX3100 uarts, but today I'd just program up one of
the smaller AVRs for the ports, and get less cost, less hassle, more smarts.

It was also doing some realtime signal processing on an interrupt.



--
> Feel the power of the dark side!  Atmel AVR

2006\04\24@121625 by Matt Pobursky

flavicon
face
On Mon, 24 Apr 2006 08:02:47 -0700, Chops wrote:
> Ten of 115200bps is a pretty non-trivial task.  By my calculations,
> it gives you about 4 microseconds per character to do... everything.

Very true -- this issue comes up on the Rabbit Semiconductor users
group frequently... The R3000 CPU has six UART channels and the Rabbit
C compilers all provide interrupt driven serial library routines.
Invariably, some newbie asks "why am I missing characters when I try to
run 4 (or 6) serial ports at 115Kbps?".

In fact, even one channel of data at 115Kbps is quite a load for most
lowly 8 bit controllers running at a moderate clock rate.

Matt Pobursky
Maximum Performance Systems

2006\04\24@123546 by M. Adam Davis

face picon face
If I recall, The FTDI website details how the 245 series are
multiprotocol engines.  You should be able to make an I2C, SPI, or
similar 2 or 3 wire bus out of them.  Then hook as many uarts as you
need (look at the Maxim MAX3140 for a UART with built in RS-485
transceivers) to the bus.

The upshot is that the less you have in hardware, the more software
you'll have to deal with and vice versa.  If you want something that
automatically looks like a serial port to the PC without writing any
software then using a USB hub chip with the latest FTDI dual uart
chips is the obvious solution.

Alternately you can use an Atmel AT91SAM7S series processor with built
in USB, write a ton of software and bit bang 8 or 10  115kbps serial
streams.  This would certainly be cheaper hardware, but a lot of work
for software.

So to get better guidance, you may consider constraining the problem
by answering the following questions:
Do the serial ports need to look like normal PC serial ports, or are
you interfacing to a custom program?
Is this a one-off project, will several be built, or will it be mass produced?
Do you have the resources to develop both firmware and PC software at
the driver level?
Is the project time frame very quick, a few months, or "it's done when
it's done"?
Is there a size, power, cost, or other physical constraint to the end product?

Good luck!

-Adam

On 4/24/06, Simon.NieldspamKILLspamquantel.com <.....Simon.NieldKILLspamspam.....quantel.com> wrote:
{Quote hidden}

> -

2006\04\24@135347 by Hazelwood Lyle

flavicon
face
> The upshot is that the less you have in hardware, the more software
> you'll have to deal with and vice versa.  If you want something that
> automatically looks like a serial port to the PC without writing any
> software then using a USB hub chip with the latest FTDI dual uart
> chips is the obvious solution.

I wonder if the overall performance would differ between using a big USB
Hub, or adding an additional USB PCI card?
Assuming USB 2.0, I would think the bandwidth to the "Big Hub" would be
more than adequate, but I'd love to know what other things would factor
into the overall efficiency.

Just Curious.

Lyle

2006\04\24@135425 by Wouter van Ooijen

face picon face
> Alternately you can use an Atmel AT91SAM7S series processor with built
> in USB, write a ton of software and bit bang 8 or 10  115kbps serial
> streams.

Maybe easier: an Atmel (or Philips) ARM with build-in USB, plus a bunch
of PICs each doing the UART parts. Communicate with SPI, or even
parallel.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\04\24@161536 by Rolf

face picon face
Hazelwood Lyle wrote:
>> The upshot is that the less you have in hardware, the more software
>> you'll have to deal with and vice versa.  If you want something that
>> automatically looks like a serial port to the PC without writing any
>> software then using a USB hub chip with the latest FTDI dual uart
>> chips is the obvious solution.
>>    
>
> I wonder if the overall performance would differ between using a big USB
> Hub, or adding an additional USB PCI card?
> Assuming USB 2.0, I would think the bandwidth to the "Big Hub" would be
> more than adequate, but I'd love to know what other things would factor
> into the overall efficiency.
>
> Just Curious.
>
> Lyle
>
>  
Hmmm. maybe that's the solution... get a real 4-port USB hub. Break out
the main board, and put Dual FTDI's on the USB outputs (maybe de-solder
the USB-A connectors, and replace with a custom-built-but-pin-compatible
daughter-card with the FTDI's on.

Rolf

2006\04\25@000239 by Robert Ammerman

picon face
> On Mon, 24 Apr 2006 08:02:47 -0700, Chops wrote:
>> Ten of 115200bps is a pretty non-trivial task.  By my calculations,
>> it gives you about 4 microseconds per character to do... everything.
>
> Very true -- this issue comes up on the Rabbit Semiconductor users
> group frequently... The R3000 CPU has six UART channels and the Rabbit
> C compilers all provide interrupt driven serial library routines.
> Invariably, some newbie asks "why am I missing characters when I try to
> run 4 (or 6) serial ports at 115Kbps?".
>
> In fact, even one channel of data at 115Kbps is quite a load for most
> lowly 8 bit controllers running at a moderate clock rate.
>
> Matt Pobursky
> Maximum Performance Systems

Absolutely.

Some years ago I developed a system based on an x86 platform that used many
high speed UARTs. The UARTs were not the standard ones used by PCs, but
rather Zilog SCC chips. As originally designed, the system ran under
Borland's 32-bit DOS extender. Unfortunately, it turned out to be completely
unworkable, even with a 200MHz+ 32-bit CPU, because of the ridiculously long
pathlengh in handling interrupts in the DOS extender. I eventually had to
develop my own Win32 subset equivalent kernel that processed the character
interrupts with almost no overhead. It works really well now!

A similar example is when one of my customers insisted that his PDP-73 could
easily handle multiple 9600 bps serial data streams. Again, this turned out
to be a disaster and in this case we had to crank the data rate down to 2400
bps to get the application to work at all. :-(

Bob Ammerman
RAm Systems

2006\04\25@001531 by David VanHorn

picon face
>
> Unfortunately, it turned out to be completely
> unworkable, even with a 200MHz+ 32-bit CPU, because of the ridiculously
> long
> pathlengh in handling interrupts in the DOS extender. I eventually had to
> develop my own Win32 subset equivalent kernel that processed the character
> interrupts with almost no overhead. It works really well now!


Yup.  Amazing what a difference it makes, when you don't throw away cycles
like water :)

--
> Feel the power of the dark side!  Atmel AVR

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...