parallel digital communication with DIO board

[philz]

Hi,

I have a USB-6229, and I'm trying to use the C++ API to create a protocol for synchronous parallel communication to an FPGA.  Using eight of the pins from port0, I've succeeded in getting it to spit out a buffer using the 100khztimebase as a reference clock, but some questions still need to be answered before I can make the fpga communicate with it.

1. I've been trying to expose the 100khztimebase internal terminal to an external pin, so that I can wire it over as a reference clock, but I cant find the right function.  DAQmxConnectTerms does not recognize 100khztimebase as a terminal.  Is there any such function?

2. Even if I were to expose the clock, I would either need an enable signal or to generate clock edges only when there was new data there.  The buffer on the NI board's side will starve, because the data is streaming, and I need it to not send repeat bytes.

3. This is more of an inconvenience than anything else, but port0 on the 6229 is a 32-bit dio port, and I am using lines 15-7 (because line0 is not cooperating for some reason).  The API does not seem to like me using DAQmxWriteDigitalU8, and instead wants me to use U32, with the byte I want to transmit shifted up to bits 15-7.  Is this normal, or am I doing something wrong?

Sorry for the novice questions, I've never worked with NI boards outside LV, and LV isn't really an option with this project.  I feel like someone has definitely done this before, but I can't find anything in documentation, forums, or KB...

Thanks!
-Phil

[TheWoost]

Hi Phil,

I'll try and address your questions:

1.  When you use the DAQmxConnectTerms function, does it have an enum list of available terminals?  In the LabVIEW environment the enum list does not include the 100kHz timebase by default.  The option must be selected to include advanced terminals.  If you are trying to export this timebase to a PFI line, try using the string /Dev1/100kHzTimebase as the source terminal.  This timebase can be exported, but according to the Device Routes list in MAX, it must use an indirect route to a PFI line through a counter source terminal.

2.  If you were successful with the DAQmxConnectTerms function, perhaps you could disconnect the terminals by calling DAQmxDisconnectTerms once your generation task has completed.  Otherwise the timebase will always be exported to the PFI line because calling DAQmxConnectTerms commits the route to hardware.

3.  What kind of behavior are you seeing when trying to use line0?  As far as needing to use the U32 datatype, this is the way the API is designed.  The DAQmx drivers respect line ordering within a port, and therefore requires that a datatype of the full port width is used.

Regards,
Andrew W
National Instruments

[philz]

Hi Andrew,

Thanks for the helpful response.  The first two questions are really not an issue anymore, since I decided to generate the clock off-board on the FPGA, so exporting the 100khz timebase is not a problem.  The 100khz timebase did not appear in the listing of available terminals in the API documentation, so it makes sense that it would need to be routed through a counter source first.  I didn't even realize that was an option.

About the third question...line0 for some reason is stuck at ground, and when I feed it alternating zeros and ones, it wiggles very very slightly in the millivolt range.  It might be a bad pull-up or something in the control circuitry, I don't know, it just doesn't seem to work.  And the response to the rest of it is consistent with what I'm seeing and read in the docs.  I initially thought that if I created a virtual port eight bits wide, I would be able to write to it with U8s to make my life easier, but apparently not.  I was also concerned that writing U32's would interfere with my efforts to use another eight pins as an 8-bit input...but it doesnt seem to.

I suppose the only question I have left is, is there example code for bi-directional parallel digital communication using this board?  I'm fairly certain I know how to make it all work, but the whole task start/stop process is really taking a bite out of my bandwidth. (Pun not intended)  I'd love to see how people before approached this or similar problems...

Thanks,
-Phil

[TheWoost]

Hi Phil,

It sounds like there may be a hardware failure with that first digital line, and a repair may be necessary.  You can call our customer service line at (800) 531-5066 to get this process started.

Unfortunately simultaneous bidirectional operations are not available with the device you are using.  The task must be started and stopped for each of the read/write tasks on port0.  However, there are devices such as the PXI-6552 and PXI-6551 in our high speed digital I/O product line that do support per-clock cycle, per-channel direction control.

Regards,
Andrew