Re: [N8VEM: 13789] 16C550C UART Auto Flow Control

-Wayne

On Sunday, June 10, 2012 7:33:38 PM UTC-7, Terry wrote:

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.