Where is the register-level spec for the NI-4462?

[RichardNeiill]

I've just bought a NI-4462 card. While the card's hardware is exceptionally good, the kernel driver under Linux is crippled by being restircted to 32-bit kernels with only 4 GB of RAM (and it's a binary blob which doesn't support any current distro's kernel either). So we're trying to write a "proper" Linux driver for it (the aim is eventually to have something GPL-d and in-tree). We've suitably instrumented NiKAL, but really need some kind of specification for the card registers...does anyone have such a thing?

[Steven_T]

Hello,

We do not currently have any register level programming guides for the 446x that are ready to release to end users.  Please contact your local NI sales representative so that we can better understand your application and needs.

Thanks,

Steven T.

[RichardNeiill]

Thanks. I already did that - the advice was to post here.

Summary: we need a driver for the NI-4462 that:

  - works on a modern Linux distro (all the officially supported ones are already end-of-lifed)

  - works on a 64-bit system with > 4 GB RAM.

  - if at all possible, has an in-tree GPL kernel driver.

So we're hoping to write a driver using your DDK, but you don't list the essential specs for the card...

We're willing to sign an NDA if necessary.

Thanks,

Richard

[RichardNeiill]

Thank you for your forthright comment, which someone very quickly deleted. I quote it here for reference and posterity:

"Hey,

He is a single user with no further sales pot etial.
It's not worth any more effort to create this document.

I'll just ask the UK AE's to let the customer know that its not possible.

Thanks for your help.

Adam"

Without rising to the bait, I'd like to point out that you are wrong.

1.  If the camera system works, we'll deploy it to MRO, which would mean another 12 cards; the design would also be published.

2.  We're offering to do NI's work gratis, and create the kernel driver that NI ought to have supplied. This means more sales opportunity for you.

3.  You don't need to put work in to creating a new document - it must already exist, because the people who wrote NIKAL must have worked from something.

4. A customer who feels he has been treated dishonestly (you sold me a card "with Linux support"; this is true on a technicality, but wrong in practice) isn't something you'd want.

[JoeFriedchicken]

Hi Richard,

My name is Joe and I'm one of the R&D developers responsible for the different DDK flavors. I apologize for the comment from Adam -- there was a blatant break in communication between my group and the UK office. It appears that you did contact your field sales engineer, who forwarded your questions to the application engineers, who in turn sent them to me.

And so we've come full circle having gone the long way, and I would like to say two things:

1. I am currently working with my group to see how we can help customers get 64-bit Linux support, and a few possibilities are coming into focus.
2. My R&D team decides which hardware families to support in the DDK, and as Steven stated, we do not have a 446x DDK that is ready to release to customers. However, as implied in the item above, there may be some options worth exploring.

I am committed to fully understanding your requirements and goals, and I want to help you reach them as much as I can. Neither NI nor I can be all things to all customers, but we DDK folk take pride in our light and dextrous code. May I contact you off-line to continue this discussion? With your permission, I can ask the forum administrators to give me your email address.

[RichardNeiill]

Dear Joe,

Thanks for your reply - yes, feel free to correspond with me in person at:

  ni - at - richardneill - dot - org    (spam-block; re-assemble into email address)

In terms of requirements, the ideal solution would be for the card to "just work" with Linux - that would effectively mean an in-kernel driver, probably part of COMEDI.

We'd attempt to write this if there were the relevant register docs within the DDK.

I expect that such a driver should be comparatively simple - perhaps 20 get/set values within sysfs, and then some means of reading data out.

An in-kernel driver also means that you don't have to constantly worry about which distribution is "supported" - there is no stable kernel ABI, but updating in-tree drivers is always the responsibility of whoever "breaks" them with an incompatible change. So customers won't ever get between a rock (NI only supports older kernels) and a hard-place (their other hardware requires a newer kernel), as I just did (my motherboard's ethernet card didn't work with any of the NI-supported distros!)

Regards,

Richard

[JoeFriedchicken]

Hi Richard,

That email address doesn't bounce, but it may be forwarded to /dev/null or the like. I thought I would try one more time here in case you didn't see my email -- is there another address I should try?

[pantxod]

Hi,

Was this private discussion fruitful? Did it lead to any advances in building a driver compatible with modern linux kernels?

At least I still don't see ni PCI/PXI4462 in the list of hardwares supported by comedi.

Pantxo

[RichardNeiill]

Here's my latest on this: I hope it helps you.

http://richardneill.org/src/ni4462/

[pantxod]

Many thanks Richard for the quick reply. This is much more hack than I hoped. I'll probably stick to my old scientific linux untill the hardware is dead.