Gee-Whiz USB to GP-IB converter

[jerriatric]

Has anyone else tried this device? I built it using the Pre-Programed PIC, it partly works with an HP Thinkjet printer but not at all with an
HP 1631D logic analyser. Using the logic analyser to watch the interface when talking to the printer via the converter, it appears that EOI is not being asserted at the end of GP-IB messages, when CTRL(J) is sent via Hyperterm, although looking at the software listing this should work...

[andersg]

Yes, I have had emails from several who have built the project. Hard to say what the problem is though, but if you have the original code, then theremay be subthe bugs in it. I have revised the code several times since I wrote the article. Do you have access to a PIC programmer? If so, download the updated code and try.

It might also be worth while to put it in verbose mode and check that an EOI i actually being sent. In that case, you should see on screen. EOI is only sent if the last character of the string is an LF.

[jerriatric]

I am using the pre-programmed PIC from the Elektor shop.
I have a PIC programmer but have been having some difficulty
finding the right directory in the current Microchip Solutions which is
now c:\microchip solutions v2012-10-15
Some of the subdirectories seem to be different?

[andersg]

That is unfortunately what happens at times. It is now 2 years since I wrote the original article and Microchip has revised their USB toolkit. I will have a look at it and recompile with the new toolkit, but for now, I have posted the latest FW as a hexfile on my project webpage. I have also added some useful comments about thoubleshooting. See http://www.dalton.ax/gpib/

FWIW, the FW was written using the Microchip toolkit from Feb 2010 and compiled/linked with:
Language tool versions: mpasmwin.exe v5.35, mplink.exe v4.35, mcc18.exe v3.35

[jerriatric]

Thanks for your help,
Successful programming of the PIC using your latest hex code.
Substantial improvements, I can reliably print single lines on my HP Thinkjet now. Still not working with my HP 1631D logic analyser, but
will persevere and let you know how I get on. Not too easy since idealy
I need the analyser to debug the Converter!

[andersg]

FWIW, I used a very simple app called digitrace and a parallell port when I developed the adapter. Also, if you enable verbose you should get more info on screen that might aid in troubleshooting.

But I admit, that I had to do some serious head-scratching before I figured out how to send commands to my HP DMM.

I have two more GPIB units arriving later this year. Will update the project page when I have interfaced them.

[jerriatric]

Still failed to get this working with my 1613D logic analyser! The analyser likes to send/receive up to 10K bytes data in one transfer.
Do you buffer all the data in the PIC's RAM before sending it over USB?
For anyone interested in getting an HP1631 series analyser working, I have now a prototype board up and running using an ATMega162. I "cheated" on the USB side though by using an FTDI based serial TTL to USB convertor. I can upload/download configuration and analysis
results to my linux netbook using GtkTerm.

[andersg]

Yes, data is buffered. I guess that is why it fails. I will have a look at it later.

FWIW, I have used it with a HP3852 Data Aquisition system that has an internal buffer and that transfers data in large chunks without any problems, but I will set it up to gather as much data as to fill up the buffer and see if I can replicate the issue.

If there is a problem, then it should be fairly trivial to fix. I also have a HP 1631D incoming to test with.

[andersg]

OK. Here is an update:

I was not able to duplicate with my HP3852 and having it to output hundreds of readings, so the bffering and handshaking is OK. I did however find a problem whem I tested dumping graphics from the HP 1631D that I bought last autumn.

The problem is that it fails on binary data. When dumping a text screen all is fine, but when you dump a graphics screen, the analyser will send rows of pixels, 72 bytes each. That row may contains zeroes. If you look at the code in ProcessIo.c, you see:

putsUSBUSART(gpib_buff);

This will only send data up and until the first NULL character, so rem out that line and the line before that and change:

[gpib_ptr]=0;// Not good in case buffer contains binary data!
//putsUSBUSART(gpib_buff);
mUSBUSARTTxRam(gpib_buff ,gpib_ptr); // See cdc.h

With this change it outputs graphic screen dumps just fine. See attachment

Left to fix is the abilty to SEND binary data

[andersg]

OK: Talking to myself here, but an updated firmware is on the way. That version will make the unit "Prologix-compatible", ie it will support enough of the Prologix (r) command set to be able to work with EZGPIB and the GPIB toolset from KE5FX.

The code is also updated for the latest (microchip_solutions_v2013-06-15) USB code.

I expect to have the updated FW posted on my project page, along with an utility to capture screen dumps from HP instruments and allow saving and restoring settings from a HP163X, by october at the latest.