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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/n8vem?hl=en.