NARA 5SDH-2
NARA 5SDH-2
There are two drivers in this family. One driver is for ISA boards and the other is for PCI boards.
Both drivers behave identically terms of handling IOTRANS lists. They do differ in other ways however, mostly in the area of interrupt processing.
It’s possible that at some time in the future they will be combined into one driver.
See the ISA driver description and PCI driver description sections below for more information.
Presently the driver supports two card types: ICS Advent PCDIO24B-P and ICS Advent PCDIO48B-P.
Up to four cards may be managed by either driver. The drivers use one major device number and different minor device numbers for each card and buss within the card. See the section Minor device number usage for more information about minor number usage.
At this time no interrupt processing is implemented because neither of the supported cards is capable of generating an interrupt which is useful for kitchen buss.
See the section ISA driver module installation for information about loading and using the driver.
Presently the driver supports one card type: ICS Advent PCI-DIO24HD.
The card is autodetected by the driver and resources such as base address and interrupt number are automatically allocated.
Up to four cards may be managed by the driver. The driver uses one major device number and different minor device numbers for each card and buss within the card. See the section Minor device number usage for more information about minor number usage.
Board level interrupt processing is supported. This particular board uses an edge triggered interrupt. The interrupt occurs on the low to high transition of the interrupt line (pin 22). This means that only one board which generates interrupts can be connected to a particular buss.
Pin 20 for this board is an interrupt gate input. This line needs to be high for interrupts to occur.
There are two jumpers on the board related to interrupt operation. The jumper for IRQD must be installed and the INTSEL0 jumper must be in the "ext" position.
See the section PCI driver module installation for information about loading and using the driver.
A device probe is NOT performed by the driver.
Up to four boards are supported by the driver.
Several arguments to insmod(8) are provided.
major may be used to set the major device number when the module is installed. The major device number defaults to 71 if not specified.
io is used to set the base address. If not specified the default base address is 0x300. See the hardware manual for a list of valid base addresses and jumper information.
enable_s2 with a value of 1 may be used to enable the S2 line.
isa_bd_type is used to select which type of board to install.
0 = ICS Advent PCDIO24B-P
1 = ICS Advent PCDIO48B-P
Multiple boards require that the io directive be used to make the driver aware of the boards and to specify the base address of each board.
The default base address for the first board is 0x300. If that is OK and there is only one board then no io directive needs to be specified.
Otherwise, the io directive must be used to specify each board in the system (including the first board).
For example, to install three PCDIO24 boards with the base addresses 0x300, 0x310, and 0x320 use:
insmod io=0x300,0x310,0x320
The boards will be given minor numbers 0, 10, and 20.
To install a PCDIO24 as the first board and a PCDIO48 board as the second board with the base addresses 0x300, and 0x310 use:
insmod io=0x300,0x310 bd_type=0,1
If you are upgrading from an older system which contains a single board likely you need to do nothing new except possibly change the driver name since loading the driver with no arguments (or the same arguments used with the old driver) produces the same behavior as previous versions of the driver.
The major device number may be set when the module is installed by "major=<major_dev_number>". The major device number defaults to 71 if not specified.
A device probe is performed by the driver when it is installed. This establishes the base address automatically.
The enable_s2=1 argument may be used to enable the S2 line.
For example:
/sbin/insmod pci_kbussdrv_24.o major=81
or possibly:
/sbin/insmod pci_kbussdrv_24.o enable_s2=1
Here are some examples:
0 - first board, 1st bus
1 - first board, 2nd bus
2 - first board, 3rd bus
3 - first board, 4th bus
10 - second board, 1st bus
11 - second board, 2nd bus
12 - second board, 3rd bus
13 - second board, 4th bus
20 - third board, 1st bus
21 - third board, 2nd bus
22 - third board, 3rd bus
30 - fourth board, 1st bus
etc.
One device node needs to be added to /dev for each board managed by this driver.
For example:
mknod /dev/kbuss0 c 81 0
mknod /dev/kbuss10 c 81 10
mknod /dev/kbuss20 c 81 20
After the nodes are made write permissions should be changed as follows:
chmod 666 /dev/kbuss*
The I/O list is composed of one IOTRANS record and one IODATA record. One I/O transaction is performed.
The I/O list is composed of one IOTRANS record and multiple IODATA records. An I/O transaction is performed for each IODATA record. The transaction starts with the address given in the IOTRANS record. N and A are incremented as appropriate after every transaction.
There isn’t a Q or X status in kbuss therefore it isn’t possible to *completely* implement an equivalant I/O transaction.
The way it is implemented in CAMAC is that it repeats the transaction without incrementing the address or moving onward to another IODATA record until Q is true.
This mode is implemented in exactly the same way as CAMstop in order to provide a complete suite of transaction types.
The I/O list is composed of one IOTRANS record and multiple IODATA records. An I/O transaction is performed for each IODATA record. Each transaction uses the address given in the IOTRANS record. Transactions continue until the IODATA record list is exhausted or until IOTRANS.Count is exhausted.
The difference between the CAMAC and kbuss implementation is that the CAMAC version will also stop on NoQ or NoX. There isn’t a Q or X status in kbuss therefore it isn’t possible to implement an I/O transaction of this nature.
The I/O list is composed of one IOTRANS record, one IODMABUF record, and a data buffer pointed to by the IODMABUF record.
Calling this a "dma" mode is somewhat incorrect. This really is a block transfer mode. There isn’t any "real" DMA in kbuss, all transfers are done using programmed I/O.
The primary difference between the block transfer modes and the "normal" modes is that the block modes use a buffer to hold the data to be transfered where the "normal" modes use an IODATA record to hold each datum which is written to or read from the hardware.
There are tradeoffs. The IODATA record contains fields for status, previous status, and previous value. This means that the status each and every buss transaction is available. The "prev" fields are not used by the driver but can by used directly by the application or by other other functions in iolib that need to differentiate between the current and previous values.
The block mode approach only deals with the current values in the buffer. The overall status of the transfer is stored in the IODMABUF.CurStatus field. There is no previous value or status information. The advantanges of block mode are that it’s a bit faster, takes up less memory, and it may be easier for the application to deal with the data.
IOTRANS.Count is the number of values to transfer. The number of bytes involved in each transfer depends on what function code is used.
For example, if Count=10 and KBUSS_func_rd8 is used the 10 bytes will be transfered from the hardware. If Count=10 and KBUSS_func_rd16 is used the 20 bytes will be transfered from the hardware.
The IOTRANS.WordSize field is not used by the driver, however it should be set the the properly word size to ensure that other functions in iolib such as extractDMAvalue() and insertDMAvalue() work properly.
Note that the card must support interrupts for this to work.
Note that the card must support interrupts for this to work.
Note that the card must support interrupts for this to work.
The assignable meter/knob system and the FP4D do NOT require use of this line.
The kbuss version of the MBS board DOES require use of this line.
The S2 line may be enabled/disabled by use of the ioctl operations after the driver is installed or by the enable_s2 command line argument.
The IOTRANS.WordSize field is not used. All kbuss registers are 8 bits, therefore transactions involving larger bit sizes are determined by using different function codes.
The IOTRANS.ADflag field is not used. There is nothing in the kbuss architecture to support it.
The following I/O function codes are implemented.
See kbuss.h for more information.
The 12 bit address space is subdivided into three groups of four bits.
Bits 11-8 are mapped to IOTRANS.cnaf.C. This is used to select which card in a kbuss system is to be addressed. Usually the card has a 4 position DIP switch to set the base address. Valid addresses are 0-15.
Bits 7-4 are mapped to IOTRANS.cnaf.N. This and the A bits together form an 8 bit address space for each card. The card is designed so that similiar functionality is grouped together within the N range of the card. For example, the registers to access the D/A convertors are grouped within one N area. The range of N is 0-15.
Bits 3-0 are mapped to IOTRANS.cnaf.A. The range of A is 0-15.
1) multiple
cards are supported
2) multiple busses within a card are supported
3) interrupts are supported
When upgrading AccelNET in a system with a single board (the most common case) everything should work by loading the driver in the same way as was done before the upgrade.
Don’t try loading both drivers at the same time without specifying different major device numbers for each one.
Many (most?) AccelNET programs attempt to open /dev/kbuss. In a system with a single board it is enough to create /dev/kbuss as has been done previously.
In a system with multiple boards it’s necessary to create multiple device nodes as described above. It might be a good idea to create a logical link between /dev/kbuss and one of the hardware nodes.
AccelNET programs will (of course) be upgraded over time and as the need arises to allow specifying which node to open. - 8-31-04rlk
