8251 troubles

[Allison]

>
>Subject: Re: 8251 troubles
>   From: Brent Hilpert <hilpert at cs.ubc.ca>
>   Date: Tue, 29 Apr 2008 00:50:50 -0800
>     To: General at priv-edtnaa04.telusplanet.net,
> "Discussion at priv-edtnaa04.telusplanet.net":On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
>
>
>
>Allison wrote:
>> 
>> >
>> >Subject: Re: 8251 troubles
>> >   From: Brent Hilpert <hilpert at cs.ubc.ca>
>> >   Date: Mon, 28 Apr 2008 13:22:08 -0800
>> >     To: General at priv-edtnaa03.telusplanet.net,
>> > "Discussion at priv-edtnaa03.telusplanet.net":On-Topic and Off-Topic Posts
>> > <cctalk at classiccmp.org>
>> >
>> >dwight elvey wrote:
>> >>
>> >>  Hi
>> >>   The routines SETUP and COUT are ROM routines.
>> >> SETUP passes the first byte to the clock generator and the
>> >> remaining to the command port of the 8251. The command/status
>> >> port is 1 while the data is 0.
>> >>  COUT sends text to a video board.
>> >> The second COUT never seems to get executed?? I give plenty
>> >> of time between characters because I send then manually.
>> >>  The board can do interrupt driven serial but that didn't seem to
>> >> work so I went for the simpler polling method.
>> >>
>> >>          DI
>> >>           CALL SETUP
>> >> ;         .DB    $01F  ; 9600
>> >> ;         .DB    $01D  ; 4800
>> >>           .DB    $01B  ; 2400
>> >> ;         .DB    $019  ; 1200
>> >>           .DB    $0AA  ; SYNC
>> >>           .DB    $0AA  ; SYNC
>> >>           .DB    $040  ; RESET
>> >>           .DB    $0CE  ;  2STOP, NO PARITY, 8BIT , X16
>> >>           .DB    $010  ; CLEAR ERRORS
>> >>           .DB    0
>> >>
>> >>           MVI    A,$027  ; RTD, DTR AND REC-EN TX-EN
>> >>           OUT    1
>> >>
>> >>           CALL   TIN
>> >>
>> >>           CALL   COUT  ; This works
>> >>
>> >>           CALL   TIN
>> >>
>> >>           CALL   COUT ; never gets here
>> >> ......................................
>> >>
>> >> TIN:
>> >>           IN     1
>> >>           ANI    2
>> >>           JZ     TIN
>> >>           IN     0
>> >>           RET
>> >
>> >I have the datasheet for the 8251A but not the 8251 here, so just some guesses:
>> 
>> They are the same except for timing and some quirks/bugs.
>
>Well, in general, differential quirks/bugs can go a long way to being a problem.
>There's a fair set of differences listed in the A datasheet.

I know, I was product engineer for NEC when 8251AC was released.

>
>> >  - perhaps the 8251 (as opposed to the A) requires the receiver to be re-enabled
>> >    (not a full reset) after receipt of each character (an 'explicit ack') (?).
>> 
>> Not required.
>
>OK.
>
>
>> >  - .. check the error flags to see if a framing error is occurring?
>> 
>> You don't have to but it's an idea.
>> 
>> >  - .. try sending a stream of (best random) characters at full rate,
>> >    as opposed to just 2 manually? This might get around some framing
>> >    inconsistency or such to at least see if a subsequent character can be received.
>> 
>> ??why.
>
>8251A doc says device is picky about seeing the STOP bit.
>Suppose for example, there is an inconsistency between the framing being sent
>and the rcvr cfg, returns first character ok but sends dev into error state,
>and error state does something to subsequent characters returned.
>In general, it might help tease out an otherwise consistent consequence of some
>unexpected behaviour.

It is a bit picky bit then that would creat a framing error and it will still 
recieve the next byte.  The only "error state" is that the framing flag is 
set and if you didn't check it on a byte by bye basis you have no clue what 
byte caused it, it continues to recieve (async).  Generally the device is 
very stupid.

>> >  - (may be inconsequential, but in the init sequence the two sync characters
>> >    are not preceded by a mode byte (perhaps SETUP does this internally?))
>> 
>> Thats required only for SYNC mode not async.
>
>As Dwight has explained they are there for a reliable init, even for async
>mode. I was noticing that it's different than what is suggested for init in the
>A doc, which is to write 3 nuls to the command register followed by a reset 
command.

You do that for any 8251 on reset as a matter of course as you may not know 
the prior state and you always get to a initial command state.  I always 
do it but I find for async unless you have a flakey hardware reset it's
not usually required thing for async.

Like I said I use it a lot as I have a potload of them (both A and non A)
from multiple vendors.  I laso have many system that thats the primary 
serial IO.  NS* horizon, NS* advantage, SBC880 and the companion 5 port 
serial card, Vt180 used 4 of them and I have load of them as well.  I 
do use and program the part still.  For Bisync its a disaster, for simple
async the bugs are not near as annoying.  I've seen far more problems with
things like toasted 148x drivers/recievers (and DEC 963x) and one end 
as 8n1 with the companion system as 7p1!

Other ways to break the part include no baud clock when programming,
chip clock not at least 4.5x the baud clock.  There are a few others.


Allison