			NT960 Master README 
April 18 1997
Rev[005]

TABLE OF CONTENTS
1/ Dev.nt960 (QNX4.22/4.23) and Dev32.nt960 (QNX4.23) ver[4.21j].
2/ ctty utility.
	-includes RS-485 Help.
3/ QNX4.2* tracelogging with NT960.
4/ rxt utility. 
	-Altering  FIFO timeouts and thresholds.
5/ ntload for QNX4.2*
6/ ntmon
	-nt960 monitor.
7/ Debug info
	-only for use under direction of CTI support.
8/ Dev.nt960(s) in alternate Dev(s).
9/ Firmware.
10/ Contact information.

**************************************************************************
1/ This latest release of the QNX4 NT960 drivers features a 16 bit and
32 bit driver compiled from common source. 

The 16 bit driver, Dev.nt960  is meant for compatibility with QNX4.22
The 32 bit driver, Dev32.nt960  is meant for compatibility with QNX4.23

If desired the 16 bit driver can also be ran with QNX423 if Dev16 is
running. It is recommened that Dev32.nt960 be used to QNX4.23.

Also see section 8/ (Dev.nt960 and alternate Dev(s)).

2/ ctty ver[2.02] for Intellicon and NT960 
Oct 11 1996

The ctty utility has been modified to be compatible with the NT960. This
utility is used to enable features such as  RS-485 receiver Discard and
RS-485 Transmitter disable.

Features applicable to the NT960 are...

RS-485 Transmitter Disable (+|-rts): This feature will disable the 
	transmitter when ever data transmission is completed. This is 
	accomplished by dropping DTR and bracketing the data transmission
	with the RTS signal. The combination of the two signals is fed
	to the RS-485 transmitter enable to enable or tri-state the transmitter.
	This allows more than one RS-485 transmitter to be on the same
	pair of wires. This feature is also called AutoRTS.
	See the ACMF-16 RS-485 SLIM option for more details on the 
	RS-485 hardware and the RS-485 SLIM.

RS-485 Receiver discard (+|-rxd). This feature will tell the UART to
	ignore any received characters while transmitting. This is useful
	for RS-485 1/2 duplex communications, where you would normally see
	en echo of what the transmitter sent. The option MUST be used with
	Transmitter Disable option (+|-rts). This feature is ONLY available
	when using the RS-485 SLIM on the ACMF-16.

Example:

ctty +rts < /dev/nt5		:Enable AutoRTS.
ctty +rts +rxd < /dev/nt5 	:Enable Receiver Discard.


**************************************************************************
3/ tracelogging info for Dev.nt960
April 18 1997

Dev.nt960 is compatible with the QNX trace logging features. Many of
messages that Dev.nt960 would print to the console are now directed to
the QNX trace logger. See below for details.


Dev(32).nt960 QNX4.22/423 driver trace information.

Dev.nt960 now support the QNX4 tracelogging features. Run time errors are
no longer posted to the active console, but are now posted to "tracelogger".

Simple usage..
--------------
	traceinfo -e /usr/nt960/traceinfo.cti

This will print out all the trace events recorded in Proc's trace buffer.


Detailed usage..
----------------

Step 1 - Run tracectrl to choose an appropriate severity to log. 
         tracectrl -s3 (recommended).

Step 2 - Run tracelogger to log all trace events to a file.
	tracelogger -f /usr/nt960/nt960.log

Step 3 - To dump out the current list of NT960 trace events.
	traceinfo -e /usr/nt960/traceinfo.cti /usr/nt960/nt960.log

	Note: The traceinfo.cti file can also be appended to the
	/etc/config/traceinfo file for convenience. 

The detailed usage will log ALL trace events to the supplied log file 
name. This infomation can be useful for debugging.


Some of the interesting events the Dev.nt960 will port to the tracelogger
are...

Dev.nt960 Started, ACM Reset, Parity & Framing & Overrun errors, CD ON,
CD OFF (HUP) and  Break Detect.

Note: Depending on the users application the tracelogger might log
numerous events, causing the harddisk to thrash. The tracectrl utlity
can be used to filter what events are recorded in the tracelogger. 
	tracectrl -s1   (only log severe problems)

Severity	
0	:Major fault SIG:SEG:V, should never happen 
1	:Severe, Port Restored, i960 Restart, other Hardware problems
2	:Parity, Framing, Overruns Errors.
3	:HUP, Carrier, Nt960 Booting
6	:Very commom messages, should never log.
7	:Never, Never log.
**************************************************************************
4/ rxt ver 1.03
June 12 95

rxt is a Connect Tech NT960 utility used to alter the receive and
transmit paramters in the CL-CD1440 UARTS.

USAGE

rxt <port #> <options>

Port numbering starts at zero.

The options that can be altered are...

rx=	: "rx fifo threshold", this is level at which the receive fifo will 
	fill up	to before the NT960 is interrupted. Minimum value is 1
	and the maximum value is 12. A setting of zero will set the port to 
	automatic mode. In automatic mode the timeout and threshold values 
	are determined by the firmware depending on the baud rate setting.

baud          <=2400  <=4800  <=9600  <=19200  <=57600  <=76800  <=115200
rx threshold   12      11      10      9        7        6        5  

rt=	: "rx fifo timeout", this is the time in milli seconds the CL-CD1440 
	UART will wait 	before the NT960 is interrupted. The minimum value 
	is 5mS and the maximum value is 1275ms. When the rx threshold is set 
	in automatic mode the timeout is set to 4 character times and to a 
	minumum 5ms. 


Examples...

rxt 0			<will dump setting of port 0, nt1>
rxt 4 rx=4		<will set the receive fifo threshold of port 4, nt5>
rxt 1 rx=0      	<will set port nt2 to automatic mode>

Automatic mode sets the timeout to 5ms.

**********************************************************
5/  NTLOAD V1.07
Jan 20 1997

New for this version of NTLOAD:

1) The +check option has been added. When this option is used, ntload
compares the version of firmware on the disk with the version of firmware 
in the NTHOST adapter. If the version is different, the Firmware on the 
disk is loaded. Otherwise the program simply ends. 


NTLOAD (ntload) Ver 1.07 Manual changes and addendum:

1) Firmware filenaming convention for QNX4.22.

Filename   Description
FQNIU.HEX  Firmware for all NT960 Host Adapters
FQNIU.BIN  Firmware for all NT960 Host Adapters, binary format

V1.05 of the User Manual refers to FQNIS and FQNID firmware files.
The new FQNIU files contain universal firmware that will run on
either a standard or deluxe Host Adapter.

2) ntload includes a command line switch (+ver) that allows
you to extract the version information from a .HEX file. For example,

    ntload f=fqniu +ver

will cause ntload to scan fqniu.hex for version information and display
it on stdout, without performing a ntload.

**********************************************************
6/  NTMON DOCUMENTATION		

JAN 20 1997

Recent Changes
1) ntmon32 for Dev32.nt960 created. 

Description:

NTMON (stands for NT960 MONitor) is a utility that monitors all
Intellicon-NT960 serial ports.  It obtains information from the driver
every second and only updates ports that have changed state since
the last scan.

At first glance the information provided can be very cryptic and
confusing, but after using the utility it can help considerably
in tracking down the causes of problems.

NTMON was written using "term" functions enabling it to be ran
remotely.


Syntax:
        ntmon [ -y reg_name ]

        -y reg_name
           Specifies the registered name to contact when searching
           for the Dev.nt960 driver. Only required if -y was used to
           start Dev.nt960.


Changing Screens:

To change the currently displayed information use the Left and 
Right Cursor Keys.  

To change between ports 1 to 16 and 17 to 32, etc. hit the PGUP or 
PGDOWN Keys.

To obtain help on the abbreviated headings on a given screen hit "H".

To Exit NTMON hit "X" then "Y" to confirm.


Screens:

Currently NTMON monitors the following information:
        - input buffers
        - output buffers
	- device entry 
	- port (currently blank screen)
	- NT960 UARTs (very low level)
	- ICB structure
	- OCB structure



Input Buffers:

The Input Buffer screen displays many of the key members of QSSL's
input_buffer structure.  These buffers are where QNX applications get
their data from and where Connect Tech's device driver moves its data
to.  For detailed descriptions of the fields consult QNX 4.xx
documentation.  Here is the definitions of some of the key fields:

CH      - channel number on NT960
LEN     - length of input buffer in Hex
HEAD    - selector and offset to the head of the input buffer
TAIL    - offset to the tail of the input buffer
SIZE    - number of characters currently in the input buffer
TTY     - tty number of device


Output Buffers:

The Output Buffer screen displays many of the key members of QSSL's
output_buffer structure.  These buffers are where QNX applications put
their data from and where Connect Tech's device driver gets its data
from.  For detailed descriptions of the fields consult QNX 4.xx
documentation.  Here is the definitions of some of the key fields:

CH      - channel number on NT960
LEN     - length of output buffer in Hex
HEAD    - selector and offset to the head of the output buffer
TAIL    - offset to the tail of the output buffer
SIZE    - number of characters currently in the output buffer
TTY     - tty number of device

Device Entry:

The Device Entry screen displays many of the key members of QSSL's
dev_entry structure.  For a detailed description of the information
shown consult QNX 4.xx documentation.

UART Screen 1,2 & 3:

The UART Screen(s) provide very low level information.  This info will
only have meaning if a person has a copy of the Cirrus Logic CL-CD1400
data book.  The info is provided mostly for use by Connect Tech's
support personel. 

ICB Screen:

The ICB Screen (Input Control Buffer) displays various fields used
in the input control structure internal to Connect Tech's driver.
From the user's point of view the most important information to
be reviewed here is if a port is receiving any data.  This can
be determined by noteing ports where the numbers are changing.

  
OCB Screen:

The OCB Screen (Output Control Buffer) displays various fields used
in the output control structure internal to Connect Tech's driver.
From the user's point of view the most important information to
be reviewed here is if a port is sending any data.  This can
be determined by noting ports where the numbers are changing.


**********************************************************
7/ Diags info

Diags info  dm, duart, dp, irq_cnt, drvrmem(32) and ntbatch(32).

These are some low level NT960 debugging tools, used to assist in 
debugging of NT960 problems. These should only be used under the 
direction of CTI technical support. Typicall uses are for custom
firmware development on the NT960.

dm, dp, duart  and drvrmem are all executables used to dump information
from the Nt960 driver or firmware.

ntbatch is script file that executes that above programs and builds a 
large debug file, then compresses it, preparing it for upload to 
Connect Tech for debugging.

This version of ntbatch is meant for 16 or 32 port systems.

********************************************************************
8/ Dev.nt960(s) under Multiple or different Dev(s):

Dev(32).nt960 has been upgraded to allow the -N switch to recognize more
than just a new port name prefix.

Previously, the port name prefix defaulted to "nt" but could be
changed to allow other names like tty etc so that the driver would
create I/O space names like /dev/nt1, /dev/nt2 OR /dev/tty1, /dev/tty2
OR whatever you specified with the -N as the prefix.

Now the driver allows the user to specify a path and prefix. This 
allows users to run more than one Dev(32).nt960 driver with more than 
one Dev or run a single Dev(32).nt960 in an alternate Dev from the 
other devices admins. 

For example, you can run your standard devices in the default Dev, i.e. 
Dev.ansi, Dev.ser, etc. And run Dev(32).nt960 in an alternate Dev.

a/ Example of 32 NT960 ports in alternate Dev: 

Dev &    
Dev.ansi -n 6 &
Dev.ser &
Dev32 -N /dev1 -n 34 &
Dev32.nt960 -N /dev1 -a d0000 300,10 &

This creates devices
/dev1/nt1
/dev1/nt2
.
.
/dev1/nt31
/dev1/nt32

b/ Example of 64 NT960 ports in one Dev and 64 NT960 ports in another Dev. 

Dev &    
Dev.ansi -n 6 &
Dev.ser &
Dev32 -N /dev1 -n 66 &
Dev32 -N /dev2 -n 66 &
Dev32.nt960 -N /dev1 -a d0000 300,10 &
Dev32.nt960 -N /dev2 -a d2000 304,11 -y cti/nt2 &

This creates devices
/dev1/nt1
/dev1/nt2
.
.
/dev1/nt63
/dev1/nt64

/dev2/nt1
/dev2/nt2
.
.
/dev2/nt63
/dev2/nt64

This allows users to create large systems with large numbers of
ports, possibly hundreds and not be hampered by the limitations of
Dev.

**********************************************************************
9/ Firmware. Due to the new self installing version of the NT960 drivers
and utils. The firmware is now placed in /usr/cti/nt960. Under the 
filename fqniu.hex. Be sure to load the latest firmware with ntload 
before starting the new driver.

Example: ntload f=/usr/cti/nt960/fqniu.hex
 
**********************************************************************
10/
For more information contact CTI technical support @
ph	519 836 1291
fa	519 836 4878
bbs	519 836 5848		login as bbs
email	support@connecttech.com
ftp	ftp.connecttech.com	login as anonymous
www	www.connecttech.com

