8251 troubles - test-drb@ccmp.vtda.org

29 Apr 2008

...

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