file:README

/*=============================================================================
   "pci-das6402.c" rev. 0.02            5-10-2000    (revision 0.01 4-18-2000)

    A Linux driver for the ComputerBoards PCI-DAS6402/16 data acquisition card
    (note: this driver is not for the ISA das6402)

    Copyright (C) 2000 Jim Henson's Creature Shop - LA
    written by Steve Rosenbluth
        (stever8@earthlink.net, stever@la.creatureshop.henson.com)

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

==============================================================================*/

This preliminary documentation consists of two emails:

- First correspondence (May 9 2000) -

Thank you both for your interest in helping write a device driver for
the ComputerBoards PCI-DAS6402/16 (16 bit PCI ADC, 64 channels @
100Ksps, 200Ksps single channel, DAC, programmable delays & triggers,
DIO, etc).

The driver is getting very close to being usable, but I'm having some
trouble (see below). My employer is having me develop a driver for our
needs (64-channel scans at 100KHz) but this card has many programmable
features which yourselves or others may need.

It would be best for you to obtain your own cards. I'm starting
negotiations today with ComputerBoards to try and get free cards, I have
no idea how long it will take or what they'll do for me.

Here's the story of the project so far:

This is a rather complex card with many 16 bit registers.  The User's
Manual has all the register bitmaps - you must get this.  ComputerBoards
has supplied me with two documents of pseudocode. The first is for
scatter-gather DMA transfers, the second is for single scans and IO
transfers.  Neither code works correctly when programmed in Linux. 
ComputerBoards says they are supportive of the project but cannot
allocate software engineering resources to help me at this time. 
Unfortunately, I'm not supposed to give anyone this ComputerBoards code
- but I have already coded most of it into the driver anyway.  Plus, the
Computerboards documentation is self contradictory in places, and vague
in others.

-------------------------------

The biggest problem is that while I can sucessfully generate interrupts
via the external IRQ pin, I cannot get an interrupt out of the card in
any other mode ! I have contacted PLX, the company that makes the
PCI9080 chip used on the '6402. They say I'm programming their chip
correctly. 

I actually soldered a probe to the LINTi# pin of the 9080 chip. The 9080
spec shows that the '6402 should generate an INTA# on the PCI bus when
the card asserts the LINTi# pin. I have seen the pin properly asserted
when running the WindowsNT "Instacal" test app, and I have seen it
asserted when my linux driver programs a scan sequence - but the linux
kernel never gets an IRQ after a data acquisition sequence (neither
normal Linux nor RTLinux get this irq, though both get the external IRQ
OK).
I can send the PLX9080 pdf file.

Two other kernel drivers use the PLX9080: see the Cyclades multiport
serial driver in the kernel sources.  I tried the cyclades PCI9080
initialization code, but then commented it out since it wasn't helping.

I know that the card is performing a data acquisition job when I program
one because I see this on an oscilloscope (you can see crosstalk ADC
noise on the analog input lines when there is no signal connected to
them, also, I see a pulse on the LINTi# pin.

So thereis some magic register bit or programming sequence that needs to
happen to get interrupts working. I really need help with this.

What's working :

The card is found by the driver upon insmod.
I have scripts to find the card in /proc and create a device node for
it.
Memory mapped IO works OK - I'm remapping the three address regions I
need.
The 8255 Digital IO section is working fine.
The file operations are there in skeleton form: configuration ioctls
work, also a query fop is implemented.
A user space configuration app sends ioctls to the driver.
External interrupts seem to work.
Data acquisition scans seem to happen - but no interrupts.
I see bits changing in the status regs after an ADC scan.

I don't want to send the source code it for another day: I need to
rename it in CVS,  package it, put a few more helpful comments in, and I
want to do a little more experimentation on the ADC scan so I can give
you better info.

-----------------------------------------------------------------------------

- Second correspondence (May 10 2000) -

I've learned a bit more about the card recently, details are below. First, how to use
the files in this package :

I'm compiling using gcc 2.95.2, kernel 2.2.14 pathched with RTLinux 2.3

if you want to compile in RTLinux interrupts, uncomment the extra CFLAGS in the 
Makefile and #define RTLINUX in pci-das6402.h

to compile the module do:
make -f Makefile.das6402

The "load_device" script works, it loads the module and creates a device node for it.
Put the module in your /lib/modules/2.2.xx/misc
do: depmod -a
do: load_device 1307 1d pci-das6402
But you don't really need this for development, just use insmod/rmmod. The module gets a dynamic major number (see /proc/devices).

"dmesg" will tell you a lot. run it every time you load,unload,ioctl, or read the device, the DEBUG_LEVEL preprocessor constant is set so the driver is very verbose right now.

The "das6402-config" app is for talking to the driver via ioctls.
I implemented these ioctls:

to set up a single channel-scan ("burst") of 64 channels, do this :
das6402-config b 10

To actually run the adc sequence, do a "go" command:
das6402-config g

I didn't see any activity on the pins "A/D internal pacer output" or "SSH out" during a scan (I also tried it running Instacal in NT). But, you can see adc activity (crosstalk) with an oscilloscope probe to a floating analog input line. (for verification, I put a scope on other pins of the card inside the machine - I don't recommend doing this...)

To "query" the status of various registers, do:
das6402-config q
dmesg

The "read6402" app is for a nonblocking read() of the device.
It asks for, and prints, 64 samples - and the driver always supplies them.

Unfortunately, the read of the ADC_FIFO_REG does not return sample values, it returns the value of the HDWRE_STAT_REG - god knows why.

Note that when the card is first powered up, the ADC_WRITE_PTR_REG is 0. After a channel-scan, this value changes, the value seems to be 0x6000+something, where something is in the range: 1000-3000 (12 bits).  I can't figure out what ADC_WRITE_PTR_REG and ADC_READ_PTR_REG actually do.

pci_das6402_program_adc() has several commented out attempts at programming the card.
The top one (uncommented) is the one I'm trying right now.  Its for a single 64 channel scan.  Though external interrupts work, adc end-of-scan irqs don't. I've tried dozens of tests to get these working, but no luck so far...


-Steve
