11-03-2006 04:25 PM
We obtained a 6501 and 6008 USB device and would like to run these under the QNX Neutrino operating system. We realize there is no USB driver available for QNX but hoped to develop our own.
But searching the forum I found a posting that indicates there is no DDK for USB devices. However the rest of the discussion seemed to indicate that one could interface with USB devices via the NI-DAQmx library.
So I took the QNX USB driver development kit and from the sample keyboard USB driver I created one for your devices. Now when my driver is running I can detect your device being plugged in or removed. From doing some USB queries on the device I see it's set to Bulk Transfer mode as opposed to Interrupt mode.
From looking at the documention on the device and reading your forums I understand this to mean that I must now poll your device through my driver in bulk mode. That's simple enough to do, but of course I have no idea what data to send to the device to ask for data nor any idea how to decode anything I might receive. That's the information that I basically need at this point (essentially the protocol the device understands). I have not been able to find that level of information anywhere when I looked through the sample code on the CD-Rom that ships with the device. Is this information available anywhere?
I know there is a library for Neutrino for PCI devices. Can I just use that library to encode/decode the data to be sent to the device? If so, which API calls would I need to use to talk to the 6501 and 6008 device?
11-08-2006 02:37 PM
11-09-2006 12:30 PM
1) For the Analog Channels, we noticed that the NI device could be selected to sample "N" amount of values and then send this "block" of data (at high rates). The main analog device that we use is a joystick (several actually) that will utilize the on-board power supply 5VDC across the joystick potentiometers to give us 0 to 5vdc for the full range of any joystick axis (Our own power supply could be used here as the Analog Channels do have a wider range available - "I", current limitations for inputs being observed). As far as how we want to read this: We need to sense a change immediately without having any of the data being buffered. I assume this means "continuous" (but see the set up information below). If someone moves a joystick, we need to get that data to our system computer immediately. As far as rate, I verified that our control loop rates are 10Hz for any given hydraulic proportional control valve circuit because the valve assemblies themselves can not respond to any given change that would occur faster than that. (i.e. - if you could move the joy stick at a faster rate, the valves couldn't follow it and you'd be in "catch up" mode - you couldn't physically make the vehicle move that fast anyway since you would also be reaching the physical limitation of the thrusters / response. The best setting for the Analog IN (which was not available for all channels with the Test Software) was "INPUT CONFIGURATION - RSE" ; "MODE - ON-DEMAND" (which I took to mean Real Time since the Samples and Rate value boxes are "greyed out" in that mode) and I had my values for the channel set to -0.2V for MIN and 5.10V for MAX. I interpret this to mean the input was set for a single-ended device with an approximate output of 0 to 5 VDC and I opened up the bounds a little to catch any overshoots. I set their "virtual O-Scope to NO Auto-Scale and the input looks real good. The "CONTINUOUS" setting in their software actually activates the setting boxes for amount of samples and rate - so I think the "ON-DEMAND" setting is probably effectively "read - and send - immediately", which is what we need.
I hope this helps describe what we want to use the devices for.
So the question remains about getting the protocol to program the device for these types of aquisition settings and how to interpret what we get back from the device.
01-08-2009 03:27 PM
01-08-2009 03:54 PM - edited 01-08-2009 03:54 PM
I responded to you directly via email. The situation is mostly the same as when Jeremy responded, but we do have a few options now for helping with requests for this material. Anyone interested should check the MHDDK download page for the most up to date information on USB MHDDK support.
01-29-2009 01:18 PM
I too need to write a QNX driver and I went to the MHDDK link and could not find protocol information for the USB 6259 ...is this available somewhere.
02-09-2015 08:24 PM
Could you please send me a copy of the keyboard source code driver example.
02-17-2015 09:25 AM
The keyboard source code example comes with the QNX DDK development kit. If you get that kit from QNX's website you'll have a copy of it. Of course that only works with a generic USB keyboard.
If you want the USB code for the National Instruments device you'll have to download it here. Then you have to convert that from Linux format to QNX.
09-20-2019 09:05 PM
I know this is like a decade later, but if you're still there-- did you ever get anything working?
02-06-2020 11:34 AM
I'm also interested in this. The MHDDK page (https://www.ni.com/en-us/support/documentation/supplemental/18/measurement-hardware-driver-developme...) now lists the "NI 62xx M Series MIO" as supported. The USB-6221 falls under this. Does this mean that the MHDDK supports the USB-6221 and other USB DAQs in this series? If so, would I be able to use the MHDDK to program the DAQ for reading on AI and writing on AO?