ni6509: rising edge on port 11 triggers edge detection on port 8

[pipegeek]

Howdy, folks.

I'm currently wrestling with what almost appears to be a problem in hardware.  Some background:
my group bought an NI PCI-6509 I/O board some time ago, for use in the development of an upcoming
course.  My partner and I are currently engaged in the process of writing a driver for the card, as a linux 2.6
kernel module (we determined that using the NI DDK---and thus, doing everything in userspace---was
unacceptable for our aims).

We have basic I/O fully functioning, but I've hit a brick wall with edge detection.  What I'd like to have happen
is that upon detection of a rising edge on line 0 of port a, an interrupt is generated.  While this does seem to
work, an interrupt is also generated if I cause a rising edge on line 0 of port b, where a and b are as follows:

Port A:      Port B:
8               11 (sometimes)
6               9
9               6
1               4
4               1
0               3
3               1

Now, these pairs of ports all line up such that one is above the other on the green connector block that came
with the card.  Initially, I thought that this might indicate a short between them.  But the same behaviour has
been observed even with the connector blocks entirely disconnected from the card.

I'm at a loss as to how to explain this behaviour.  As far as I can tell, my code works exactly as it should---
I've followed the guidelines presented in Static DIO Register-Level Programmer Manual for
NI 6509, 651x, 6520, 6521, and 6528 Devices to a tee.  I've called NI, but, after much research on their part,
I was told that they couldn't find a solution and that they didn't really support register-level programming anyhow.
The person I was speaking with directed me here, so, folks: any of you know what might be happening?

PTR

P. S.  The machine we're using is as follows:
O/S: SUSE Linux 10.1 (32-bit)
Kernel: Linux 2.6.16.13 (the following non-suse-default options were enabled: CONFIG_HZ_1000=y, CONFIG_PREEMPT=y)
Processor: AMD Athlon 64 3000+
RAM: 512MB
I/O board: PCI NI-6509

[rtos]

Hi,
Will you be willing to share your current driver with me. I would like to use it for some fun project I am working on.
I can be reached at toshniwal_rohit@yahoo.com
Thanks.

[Nick_Storton]

Hi Pipegeek,

Have you used the programmable input filters in combination with change detection to eliminate spurious

change detection events caused by noise or glitches. It may be that you are picking up a glitch from the adjacent pin that is large enough to cause a false detect.

Nick

[pipegeek]

---

@Nick Storton wrote:

Hi Pipegeek,

Have you used the programmable input filters in combination with change detection to eliminate spurious

change detection events caused by noise or glitches. It may be that you are picking up a glitch from the adjacent pin that is large enough to cause a false detect.

Nick

---

I just tried it (both at your suggestion and at the suggestion of a guy at NI tech support) and the problem seems to be gone.  Thank you very much for the help.

If I can get permission from the university (which may or may not happen), I intend to release this driver and its associated library (the latter of which currently has both a c++ and a partial java interface) as open source under the GPL v.2 once they're done.  I hope the community will find it handy :^)

PTR

[rtos]

Hi,
    " If I can get permission from the university (which may or may not happen), I intend to release this driver and its associated library (the latter of which         currently has both a c++ and a partial java interface) as open source under the GPL v.2 once they're done. "

This will be awesome. Appreciate your efforts and will wait for the driver if it gets released.