Yeah, I kinda figured the suggestion of an overwrite to MCR
(resetting bit 5) was a stretch, but it was the only thing I could
think of that would reset bit 5 after you set it.
Unless the chip is defective/faulty as you described.
BTW - the data sheet I'm using is for the TL16C554 - billed as four
16C550-C UARTs in one package. The Reset data page specifies the
status of all registers after a reset pulse. The info for the Modem
Control Register states: "All bits cleared (5-7 permanent)".
Of course a reset SHOULD clear all bits, but bit 5 SHOULD NOT be
listed as "permanent", since it is now the AFE control bit. I
suppose it's merely an oversight - it just didn't get updated with
the later '550-C data. Right?
I'm thinking you should give up on the 40-pin DIP UART chips and go
with the PLCC package - they're cheaper, more readily available, use
less space, and still usable in a thru-hole environment. THEN you
can use the '754 and '750 series UARTs, which allow much higher
clock rates, deeper FIFO, faster operation - lots of benefits, and I
don't know of any downside.
Final suggestion: Stick with the Stack.
(Hey! That's kinda cute!)
Best of luck!
Terry
On 6/10/2012 9:54 PM, Wayne Warthen wrote:
Thanks for all this input Terry. Greatly appreciate
it.
Unfortunately, as far as I can tell, the 16C750 is not
available in the 40 pin DIP format (that would be a fantastic
alternative if it existed). Looks like the 16C550C is the last
version to support 40 pin DIP packaging. I do see that there is
a Phillips SC16C650B chip in 40 pin DIP that might be an
alternative, but it does not seem easy to find (UTSource is the
only place I see it). The programming is not an issue, but the
packaging and pinout need to fit the existing designs.
I would love to send you some code, but there isn't any! :-)
I have done almost all of my testing by reading and writing
ports directly via the monitor. I did the same exact thing on
the Stack180 and easily proved it's UART works as advertised. I
do understand the subtlety of the MCR register and being careful
not to write to it later with a value that would undo bit 5.
That is part of why I did this with a monitor -- to make
certain no other code was getting in the way. And, in case you
might wonder, I was using a separate VDU terminal as a console
to do the testing so I was not trying to "use" the serial port I
was testing!
The one comment you make about the bit not returning as set
after I set it is the part that has me starting to believe that
there is something dreadfully wrong between the data sheet and
the chip's behavior. It is hard to understand, but it really
does seem like the chip simply does not have that feature. The
autoflow feature was brand new in this revision and they were
getting ready to deprecate the 40 pin DIP package. I almost
wonder if the 40 pin DIP version has the problem and they just
didn't care... The FIFO itself is working perfectly, it is just
the autoflow feature. It would be interesting to try a
TL16C550C in one of the newer package styles (non-DIP) to see if
the problem exists there, but I don't have a simple way to do
that.
Thanks again Terry. I will post here if I make any progress,
but am a bit burned out on this struggle for the moment. :-)
-Wayne
On Sunday, June 10, 2012 5:40:49 PM UTC-7, Terry wrote:
Wayne,
I don't have the answer you're looking for - as you already
noted, it works well
on the Stack. You might try the 16C750 in place of the
16C550-C. The 'C750 is
a single UART version of the 16C754 quad UART carried in the
Stack180. It's pin
compatible with the 16C550 B & C versions, although the
register map and bit
assignments are different, requiring some different
programming. For basic
16450- and 16550-compatible operation, they're pretty much
identical, but the
enhanced operating modes are markedly different.
For instance, although both '550 and '750 chips have versions
of auto flow
control, they are enabled and operate very differently.
If you would like, I would enjoy taking a look at the code
you're using,
particularly on the 16C550.
Two more general comments...
AFE in the 16C550-C uses bit 5 of the Modem Control Register.
For chips prior
to the 16C550-C, this bit was set to zero and would always
read back as zero,
regardless of what you wrote to it. If the bit is being set
and reads back as
reset, then it would appear that the chip labeled as a 'C'
version is not really
a 'C' chip.
Just a reminder - when we init the '450 / '550 series chips,
we almost always
output a 3 (011b) to the Modem Control Register to set the
/RTS and /CTS
outputs. You cannot do this when using AFE mode - it resets
AFE at bit 5. You
have to output a 22H to the MCR to set AFE and enable Auto
/CTS and Auto /RTS,
or output 20H to enable Auto /CTS only.
Regards,
Terry
On 6/10/2012 6:06 PM, Wayne Warthen wrote:
> Hi Folks,
>
> Has anyone gotten auto flow control to actually work with
a 16C550C UART?
> This is the UART chip I have in most of my boards and
seems to be the most
> popular one to use.
>
> I only recently found out that the TL16C550C UART is
supposed to support
> automatic hardware flow control. This was a feature that
was newly introduced
> on the 'C' revision of the part.
>
> I have now spent several hours trying to get it to
actually work with no
> success. I have proven out my cabling and testing
environment by using a
> Stack180 I built a while back. The Stack180 has a newer
generation UART, but
> I successfully got it to perform auto flow control
perfectly.
>
> I am using a serial break out box to monitor RTS. If
autoflow is working RTS
> will be deasserted when the FIFO gets close to full. I
see this behavior
> perfectly when testing with the Stack180 and the newer
UART. When I program
> my TL16C550C for autoflow, RTS is not deasserted as the
FIFO fills up and
> overflows. Additionally, when setting the autoflow
enable (AFE) bit in the
> UART, it does not read back as being set. That register
is supposed to allow
> it's value to be read back. Additionally, I can manually
turn the RTS signal
> on and off at the UART and see it on the breakout box, so
I know that the
> signal path is good and the UART is controlling RTS.
>
> It really seems like the TL16C550C does not have the
autoflow feature that is
> described in the data sheet. I have tried multiple
different chips with the
> same results (failure).
>
> I would love to hear if anyone has tried this and if
there has been any
> success. It would be really nice to get this
functionality working...
>
> Thanks!
>
> Wayne
> --
> You received this message because you are subscribed to
the Google Groups
> "N8VEM" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/n8vem/-/RD5WnXz0Rc0J.
> To post to this group, send email to n8...@googlegroups.com.
> To unsubscribe from this group, send email to n8vem+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/n8vem?hl=en.
--
You received this message because you are subscribed to the Google
Groups "N8VEM" group.
To view this discussion on the web visit https://groups.google.com/d/msg/n8vem/-/TQMtOm8HUEIJ.
To post to this group, send email to n8...@googlegroups.com.
To unsubscribe from this group, send email to
n8vem+un...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/n8vem?hl=en.
|