On 1 Feb 2010 at 22:27, Tony Duell wrote:
That sounds more like the Intel 8251 USART. IIRC on
that chip you have
to send the reset command 3 times to ensure it's treated as a command
and not as data to be loadrd into one of the configuration registers.
The problem arose because after a reset, the 8251A (the 8251 is a
miserable botch), expects a mode command upon reset. The trouble
occurs when you're trying to use the same routine to reset the chip
(command mode) and program the mode because both the mode command
bytes (1 or 3, depending on sync or async) use the same I/O port. If
you came to the routine from a power-on or external reset, the
attempted reset command would be interpreted as the first byte of a
mode sequence.
The workaround was to fire off three 00 bytes, which had no effect
other than to terminate a pending mode sequence (if any) and put the
8251A into a command state.
The next command would be an "internal reset", which would drop the
chip into a mode state, whereupon you could issue the necessary mode
bytes. Note that you had to be in the mode state to change between
synchronous or async operation, character length, parity or sync
character length (1 or 2 characters).
Yes, it was clumsy, but the 8251A was a good choice for synchronous
mode operation, so most folks sucked it up and dealt with it,
probably because the 8251A was very easy to design for DMA mode
operation.
If you could restrict your needs to asynchronous operation, there
were many other good choices.
--Chuck