LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

device to host ps2 communication

Greetings all! Looking for some help in using a PXI-6289 to emulate a keyboard. I plan on creating a 15kHz clock using a PFI line and using a digital output to send the data. The problem I'm having is finding the best way to properly format the data and sync the writes to the clock. I'm trying to used a timed loop that sends ticks on rising edges of the clock, but I'm getting bogged down in trying to get the data formatted correctly. Has anyone here done something like this? I'm wanting to know if I need to calculate the parity or if I can just send the make and break values for the characters I want to write.

 

Thanks in advance!

0 Kudos
Message 1 of 5
(2,981 Views)

Ok, I've got the parity calculation and data formatting complete, but now it seems that I can't get a timed loop to run fast enough to sync with a 15khz clock.

 

Anybody?

0 Kudos
Message 2 of 5
(2,968 Views)

Hello,

 

Unfortunately, you're not going to be able to get your timed loop in your software application to run at 15kHz. The processing speed of the PC is the limiting factor here. You do have a couple of other options, however, depending on how you actually want to speak to your host. Also, just to be clear, what exactly is the situation? You are emulating the functionality of a keyboard for a playstation 2?

 

Anyway, if you know the format of your data and you want that to be clocked at 15kHz, you're going to have to run that in hardware time and generate the data from the onboard memory as you go. This does require you to pre-load this data to the 6289, so you won't have "real time" type control over what you send to the host from the 6289. There is an example VI that basically does this. This VI pre-loads a waveform to the onboard memory of your DAQ card and then as it's generating, it replenishes the memory each iteration of its while loop. I modified this VI and have attached it to use correlated digital generation using a counter for its timing source. This option should work for you if you want continuous generation, but you'll have to know what commands you are trying to send your host, so that you can replenish the memory of the 6289 continuously.

 

The other option, is to just write a single command or a few at a time and generate them in bursts with hardware timing. This would require you to stop and start the DAQmx task in between each generation while still being able to actually generate at a rate of 15kHz in hardware time while giving you more control time between consecutive generations. The example that I have attached can basically do this, however, you would need to change the sample timing type to "finite" instead of "continuous." 

 

I hope this helps. If I'm way off base about what you're actually doing, let me know.

 

Chris W

0 Kudos
Message 3 of 5
(2,948 Views)

Chris,

Thanks for the input! What I'm trying to do is emulate a keyboard's PS2 communication protocol. I have a mass-interconnect system that connects to a unit under test. The current implementation of the test has the operator entering keystrokes (doesn't matter what they are), and I'm trying to eliminate that. As such, I just want to send keystrokes (make and break scan codes) to the unit. 

I've spent a fair amount of time on this and have run into the timing limitations you mentioned. I took a different approach and used the DAQ's ctr0 as the timing source, then built both the data packets (it's an 11-bit frame) and the clock signal. This was necessary because the clock signal only runs when a key is pressed. So, it's a clock and data burst whenever a key is pressed. I've gotten very close to making this work, but it seems that the DAQmx method is a bit more difficult that I've got time for. I'm switching to a PXI-6541 that's also in the system and I'm going to read from an HWS file and generate from that, provided the same method of packet construction I've already got won't work for the HSDIO Write.

0 Kudos
Message 4 of 5
(2,937 Views)

Hello,

 

I am not sure how you have constructed your packets, but the way you are describing the generation, I don't see any reason you cannot use the same method to prepare the data for your HSDIO Write VI. If you have all the packets created in your HWS file and a particular keystroke triggers and event that reads a particular HWS file, then you should just be able to load that and write it directly. 

 

It sounds like you are still going to be using a finite timed generation task that is basically going to be started based on an event that is perhaps bound to particular keystroke. That should work out. Are you running into any particular problems right now? It sounds like you possibly have this figured out. Is there anything in particular that is giving you trouble?

 

Chris W

0 Kudos
Message 5 of 5
(2,917 Views)