Re: [openrisc] or1k UART TX bug ?

[Marko Mlinar <markom@opencores.org>]

Scott,

I looked at the code and I think it is ok now.
I will do the simulation with Jacob's Uart hopefully in the near future and 
will let you know if there will be some issues.

thanks,
Marko


On Wednesday 02 April 2003 02:18, Scott Furman wrote:
> [Sorry that I was not able to refocus on this issue sooner.]
>
> Damjan Lampret wrote:
> > can you check 16450 and 16550 datasheet and if they differ, we can
>
> either
>
> > say we only support one of them (I'd suggest 16550 because we have
>
> developed
>
> > 16550 hardware IP core and we use it in all SoCs), or to have an
>
> option in
>
> > simulator .cfg for the type of UART and 16450 behavior can be
>
> selected.
>
>
> I had a look at several 16550 datasheets (see brief notes below).  The
> executive summary is that the 16550 can emulate the 16450 when placed in
> "character mode".  So, supporting just the 16550 doesn't really save us
> anything since the 16450 behavior is a subset of 16550 behavior.  (Also,
> note that there is already an option in sim.cfg to select between 16450
> and 16550 mode.)
>
>
>
> I was able to come up with a modest revised patch (attached) that
> changes the behavior of THRE interrupts depending on whether or not the
> UART is in character mode (16450 and 16550) or fifo mode (16550 only).
> I have tested it briefly using both eCos and uclinux.  If someone else
> is working with or1ksim UART drivers, it would be great if you could run
> with my patch and report any difficulties.
>
>
>
> More gory details below:
>
>
>
> I had a look at the datasheet for National's 16550D and also a helpful
> National app-note, "AN-493: A Comparison of the INS8250, NS16450 and
> NS16550 Series of Universal Asynchronous Receiver/Transmitters (UART)".
>
> http://www.national.com/ds/PC/PC16550D.pdf
> http://www.national.com/an/AN/AN-493.pdf
>
>
>
> Here are some relevant sections from the datasheet:
>
> Functionally identical to the 16450 on powerup (CHARACTER mode) the
> PC16550D can be put into an alternate mode (FIFO mode).
> ...
> Bit 5: This bit is the Transmitter Holding Register Empty (THRE)
> indicator. Bit 5 indicates that the UART is ready toaccept a new
> character for transmission. In addition, this bit causes the UART to
> issue an interrupt to the CPU when the Transmit Holding Register Empty
> Interrupt enable is set high. The THRE bit is set to a logic 1 when a
> character is transferred from the Transmitter Holding Register into
> theTransmitter Shift Register. The bit is reset to logic 0 concurrently
> with the loading of the Transmitter Holding Register by the CPU.  In the
> FIFO mode this bit is set when the XMIT FIFO is empty; it is cleared
> when at least 1 byte is written to the XMIT FIFO.
> ...
> When the XMIT FIFO and transmitter interrupts are enabled (FCR0e1,
> IER1e1), XMIT interrupts will occur as follows: The transmitter holding
> register interrupt (02) occurs when the XMIT FIFO is empty; it is
> cleared as soon as the transmitter holding register is written to (1 to
> 16 characters may be written to the XMIT FIFO while servicing this
> interrupt) or the IIR is read.


--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml