adding 16550 UART to RM9200

[Krassimir Slavchev]

Bernd Walter wrote:
> On Wed, Apr 04, 2007 at 11:16:28AM +0300, Krassimir Slavchev wrote:
>   
>> You may look at this:
>> http://www.nxp.com/news/content/file_1194.html
>>     
>
> Exar has something similar with the XR20M117x/XR20V117x
>
> The problem with IIC is that it is way to slow (max 400kbps) and is to
> be shared with 48 UARTS, which even invalidates the full data rate.
> You can't even run a single UART at 230kbps.
>   
Yes, you are right, it was just an idea.
> Plus IIC is quite expensive in respect of CPU time on the RM9200.
> IIC is what I do right now - an USB master electronic for ubser(4)
> plus multiple IIC connected ATMEGA8 controller doing a few software
> UART at 9600bps each.
>
> SPI may be fast enough but requires a select line per UART, which of
> course can be done via 6 to 64 decoder.
> SPI works good for bulk transfers on the RM9200, but since we are
> likely doing small transfers it is not very efficient.
>
> And it requires a complete new set of drivers.
>
> 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.
>> Bernd Walter wrote:
>>     
>>> I plan to add up to 48 16550 UART to an RM9200 system.
>>> It should be done with 16C554 chips - so I only have 16 byte FiFo.
>>> I would like to avoid using 64 byte FiFo chips, but those are pin
>>> compatible, so things are changeable in case.
>>> Likely most of the ports are doing low volume and I hope this will
>>> be Ok.
>>> They will be addressed via NCS2 space.
>>> Most of the external interrupts are not available because of
>>> unfortunate multiplexing with other required signals, so I have to
>>> attach them all to IRQ0.
>>> The interrupt will be level configured by firmware.
>>> And the NCS2 waitstates and buswidth will be configured by firmware
>>> as well.
>>>
>>> However some question points are still left:
>>>
>>> - How can I attach our uart(4) driver to the chips?
>>> It will likely addressed with:
>>> UART0	0x30000000 - 0x30000007 IRQ0
>>> UART1	0x30000008 - 0x3000000f IRQ0
>>> UART2	0x30000010 - 0x30000017 IRQ0
>>> UART3	0x30000018 - 0x3000001f IRQ0
>>> UART4	0x30000020 - 0x30000027 IRQ0
>>> UART5	0x30000028 - 0x3000002f IRQ0
>>> [...]
>>> UART47	0x30000170 - 0x30000177 IRQ0
>>> UART48	0x30000178 - 0x3000017f IRQ0
>>>
>>> - I would like to use a 14,7456MHz xtal
>>> How can I tell uart(4) the frequency?
>>>
>>> - How can I configure NCS2 range as being uncacheable?
>>> I asume this has to be done somehow in the kernel.
>>>       
>
>   


-