adding 16550 UART to RM9200

[Bernd Walter]

On Wed, Apr 04, 2007 at 03:41:07PM +0300, Krassimir Slavchev wrote:
> Bernd Walter wrote:
> >On Wed, Apr 04, 2007 at 11:16:28AM +0300, Krassimir Slavchev wrote:
> >Additionally the 16C554 is available from multiple vendors and much
> >easier to source in small volume than the IIC/SPI chips.
> >If that wouldn't be a reason I would have selected the Exar XR16L788,
> >which is a 8 channel 16550 compatible UART with 64 Byte buffers and
> >an integraded ILR.
> >
> >  
> This chip seems to be good choice. I dont now what is your application 
> but 48 uarts are too much.
> I have dial-up servers with 34 (32+2) uarts on P1 166 Mhz (FreeBSD 2.2.8 
> and 3.5.1) which work perfect for years at  38400 bps but I still get 
> "silo overflow" messages.
> It is not a bad idea to use multiplexers where you can.

The main point is to get larger buffers to reduce interrupt load no
matter how it is done.
I get the ILR with external hardware as well and I can still get
64 byte FiFo with the same PCB layout by using ST16C654 chips if
absolutely required.
I know that 48 UART is much, but I still expect that it will work for
todays use.

Dial-up pools with UART are quite uncommon use for UART these days.
People keep old equipment running, but unlikely install new one.
It is more typical to have sensor networks, console concentrators and
so on.
The whole used bandwidth with 48 UART should be much lower than with
your 34 UART dial-up scenario.
Most UART will run at 9600bps, some may use all 48 with 115200, but to
get peak performance not to have sustained 115200 traffic on all ports.

The interrupt overhead on ARM should be much lower than on i386.
Unlikely on i386 we can even reorder the priority compared to other
interrupt sources.
Possible that I loose that benefit with the interrupt sharing over
multiple ILR though.
The ithread overhead compared to 2.x and 3.x should be solved as well.
Not shure about the sio(4) vs. uart(4) performance difference.

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd at bwct.de           info at bwct.de            support at fizon.de