Propeller speaks GPIB
BradC
Posts: 2,601
So I priced GPIB interfaces, and after scraping myself off the floor I grabbed 16 100 Ohm resistors, 16 10K resistors and a $6 connector from DigiKey.
The ever multi-lingual Propeller [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
The ever multi-lingual Propeller [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Comments
My GPIB days are gone, but the idea to have such an interface is really intriguing..
Massimo
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Are you going to post the code and/or schematic ?
We have alot of GPIB equipment at my work, and I'd love to try it.
Also, what is the digi-key part # for the GPIB socket ?
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...
·
Plug : MDA24K-ND
The schematic is a doddle. 16 Propeller Pins all with 100 Ohm series resistors and 10K Pullup to +5v at the socket end.
Pins 0..7 are Data and 16..23 are Control signals. I only oriented them that way as the 26 Pin IDC I had would not really fit neatly anywhere else on the proto board.
The driver is written in SPIN. The data port is addressed with outa[noparse][[/noparse]7..0] and the control bus pins are all defined by enum, so moving things around is very easy.
It's quite surprising actually at the lack of concrete GPIB examples out there. Most of the ones I've seen have been a case of "here is the schematic and you can order the pic/avr from us for $20".
I had a hell of a time figuring it out as it turns out my 2440M has a MATE/CIIL board in it which sits between the socket and the CRO to make the scope talk CIIL rather than the standard Tektronix protocol. Once I figured out I needed to bypass that board it was a lot easier to get going. (That board was an $11,000 USD option on the cro when it was new - how technology marches on!)
I am planning on posting the code, but at the moment it's very early days and I'd like to have something that I'm slightly less embarrassed about (and is a little more flexible) before I post it for public consumption.
As this device has the ability to display messages on the screen and pass soft-key presses back up the GPIB it's very easy to write your own addons and analysers. Ultimately I want to be able to save/load traces & settings to and from SD card, and save HPGL screen dumps to SD for printing from the PC later. All in all, none of that is particularly difficult and would make quite a useful addition to the scope.
Even downloading waveforms in real time, performing analysis on them and uploading them back for display is quite a fast operation.
GPIB is a combination of tri-state and open collector pins and fortunately the signaling voltages are about the same as you use with the propeller. Lucky that [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
I haven't seen or heard about GPIB for so many years now I thought it had gone extinct.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
One of the main reasons I got started with the Propeller is because I was faced with a bunch of old clunky stuff that used GPIB, couldn't stand the thought of dealing with a bunch of old dusty junk, and just decided to start from scratch.
Yes, please do post the code, if you don't mind sharing. It would probably help resurrect some old dusty junk that is otherwise surely destined for the junkyard. You'll get karma points for helping the environment and for helping shoestring-budgeted scientists get some work done.
Definitely a worthwhile effort!
I'm surprised that GPIB is still around. I remember making my own controller over 20 years ago to work with a HP combo DSO and LA (can't remember the model, but it was very expensive). I found that GPIB is very simple really yet anything GPIB on the market is always $$$$$. "GoodOnYa" for pressing the Prop into this role.
*Peter*
I have two of these in my grubby little hand. I'm just waiting for the schematic and code files (Hint Hint).
Patiently waiting....
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...
·
Thanks Bean.
It seems finding the right connector is at least half the battle.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Watching the world pass me by, one photon at a time.
DogP
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
I really don't have any time to work on it at the moment, so when I find it and do a sanity check on the code I'll just post what I have.
I need the board to remember how I wired it up as I can't remember what I did now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I'm hoping this doesn't fall off the radar....
jr
I've recently used the Propeller to interface to some old scanning tunneling microscope hardware via its proprietary TTL 16-bit data bus. The Propeller would just translate parallel bus communication to serial PC communication (via a USB-Serial chip). The conversion was simple and quick.
I know that TI produced the TMS9914 chip many years ago and its documentation came with complete state diagrams..... but......
With tools like the Intronix USB Logic Analyzer (which I used to reverse engineer both the STM interface above and the Chatpad X360 keyboard accessory) it would seem that the most straight forward pathway would be to simply capture the digital communication between a PC and various GPIB instruments of interest using commercial GPIB adapters, then implement this same digital handshake using the Propeller. Much of the mostly superfluous stuff like serial polling, etc. need not require immediate implementation, at least not the first time around.
While I'm a little reluctant to plunge into use of RobotBasic (see a recent discussion on this forum), I find it to be a rather compelling solution in this particular case. The Propeller could be used to perform basic GPIB handshake operations with instruments, translate this into serial communication (via USB) with a PC, and then RobotBasic could provide a GUI interface for accessing that instrument's primary operations. I haven't personally tried RobotBasic but its author claims many great things.
I know that software like LabView has been available for years ... but that requires its own learning curve and lots of dollars. Consider that BOTH the Propeller Tool and RobotBasic are available at **NO COST**. Once a basic Propeller object is available, a demonstration of GPIB connectivity to a simple HP lab multimeter could be made available via OBEX. After that, it would be a simple matter for others to adapt the code to their own lab GPIB equipment and re-submit to the object exchange the appropriate code changes.
Perhaps the peculiar protocol of various GPIB instruments could be encapsulated within separate SPIN objects. A reading of current, voltage, frequency, phase, capacitance, etc. could be specified from a parameter list unique to a particular instrument ... but the method call format itself could be STANDARDIZED in an instrument independent manner. This means that while each instrument acquires different data, the MANNER in which (via the serial interface) that a PC program would request this data could be standardized.
In the end, ***FREE** PC software could be used to access multiple GPIB instruments as part of a scientific experiment, writing data to files. Alternatively, the Propeller itself could have independent control of these same instruments, running its own SPIN algorithm, perhaps filtering the data in search of a particular event signature.
Perhaps this is just a discussion of ancient history. But perhaps not. I have witnessed a few professors run their labs using QBASIC for the last 20 years !! They resisted every opportunity to upgrade their software to the latest and greatest from DOS to Windows 3.1, to XP, to Vista. They bypassed every new language over the years. Believe it or not, they are still running that old code, communicating with lock-in amplifiers, and laser equipment to this very day. They did not need to retool & retrain each new group of grad students every year or so for the last two decades (at least not in regards to software).
I think that is one of the great selling points behind the Propeller. I can comfortably recommend the use of the Propeller because of its potential over the long term: you could put a project into a closet for a decade, open it up like a time capsule, retrieve the Propeller Tool from the project zip file, and after a quick examination of the neatly arranged SPIN object code be quickly up and running. I can't imagine doing the same with any of the Microchip line of microcontrollers ..... I've been away from those devices only a few years, but that old code already seems like Greek to me.
If I don't see any new offerings of Propeller code for GPIB communication on this forum over the next few months, I'll commit to the development of my own code release. I know our department could make good use of a simple inexpensive GPIB solution. It's long over due.
Greg,
I'm happy you are considering working on this. Having some kind of GPIB interface would probably help a lot of low-budget science types stay in the game. Generally speaking, I think the Propeller has a lot of potential for helping science and engineering students build their own customized equipment and interface with others. Many years ago, science students could take courses in glass blowing so they make their own chemistry apparatus or cathode tubes, etc. so they didn't have to wait around for the machine shop to make their stuff. Nowadays microprocessors are the thing - or maybe should be.
thanks for keeping this on the radar screen,
Mark
It's ugly, but it's a start and it works. There is no licensing info in the file. Take this post as releasing it as public domain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
For anyone interested, the full IEEE-488 standard may be downloaded from a Jefferson Lab site:
hallaweb.jlab.org/tech/Detectors/public_html/manuals/data_sheets-manuals/G-I/ieee/488/
The "ANSI-IEEE Std 488.1-1987.pdf" file contains the relevant low-level protocol.
I will have to swallow a little "humble pie." While the physical interface itself is relatively uncomplicated: a 24-pin connector, with 8 data, 8 control, and 8 ground pins, there is much, much more to consider in dealing with the IEEE-488 protocol. For starters, there are 10 separate state machines, many of which may be simultaneously active, with the state of each machine involved in the conditional logic which determines the state transitions in other machines. Its all rather complicated. On the upside, its all very, very well documented. Perhaps no other interface standard has ever been so meticulously defined. If you can get to the point where the "Greek" is easy to read, the 199 page document will provide "more than you ever wanted to know" regarding the IEEE-488 GPIB protocol.
The multiple state machines could potentially be implemented within a single cog using a strategy similar to that of the full duplex serial object. The serial object could alternate back and forth quickly between transmit and receive code using the "jmpret" instruction. What was neat about the use of this instruction was that it would allow you to jump back and forth between an ever changing set of "states" of the two code sections (transmit and receive). You could extend this to GPIB, with each of the ten state machines correspond to the tx and rec sections of the serial cog code. The "jmpret" instruction would allow you to skip in round robin fashion in a loop through all ten machines, stepping into the currently active state of each machine, and exiting to the currently active state of the next machine. With each "jmpret" execution, the return address is updated to reflect the currently active state of that machine. The final machine in the loop would use its "jmpret" instruction to go back to the original "jmpret" address, only now it would be at "PC+1" executing logical tests for the original machine's active state... and so forth. Hopefully, I'm not swimming upstream with all this jmpret instruction stuff. Someone please correct me if this would not work as envisioned.
I suspect it might work as you expect it to. I also get the feeling it's needlessly complicated.
I've never seen an instrument that would require a complete ten state machine GPIB implementation. Most of the ones I've come across simply use GPIB as a stable bus oriented data exchange medium. Just start with enough code to talk to your available test equipment and expand it as you need more features.
If you were to write a complete "fully compliant" GPIB stack for the propeller, firstly I'd wager nobody would need it. Secondly, I suspect you'd never find a way of properly testing a lot of the stack for full feature compliance.
The second point is the killer. If you can't properly test each part of the stack in combination with all the others, you might just find timing glitches that corrupt data or lock up the bus under certain circumstances. Keep it as simple as you actually need.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Here's the thing I sometimes use now, it's $500:
http://sine.ni.com/nips/cds/view/p/lang/en/nid/201586
Your code, a Prop, and an FTDI chip can do the same thing for a lot less...
But, what I really want is to make a GPIB slave device...· I'm sure this will help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
www.prologix.biz/
The GPIB-USB Controller 6.0 is priced at $150 (US).
One group in our department is currently using this device.
I took the liberty of opening the case, and found :
1) an FTDI USB-Parallel chip
2) an Atmel microprocessor
.... and very little else.
So this is proof that very little hardware is required to construct a GPIB controller. If one is willing to limit max data transfer to approximately 10K bytes per sec (instead of the GPIB (1978) Spec of 1MB/sec (under special conditions), the FTDI USB-Serial chip will do just fine.
I've been reflecting over the history of GPIB:
1) In the 70s it was simple. Just use a "PRINT #13, "READ VOLTS" statement in your basic code to talk to instrument (with address 13) on the GPIB bus. It was almost as simple as printing to the screen. Those were the days !
2) Then came the IBM PC .... but without built-in GPIB support. An assortment of GPIB controller cards became available in short order. BUT ...
3) The ISA card GPIB controllers each had their own unique IRQ, IO Port, and DMA assignments and unique electronics requiring a separate driver for each controller type. If you switched controllers, you recompiled your code with new drivers.
4) Texas Instruments introduced the TMS9914 GPIB-interface chip. It became the defacto industry standard. Anyone reading the User Guide to this chip (or the 200 page GPIB specification) was immediately reluctant to plunge into the murky world of multiple state machines inter-coupled.
5) National Instruments gained market share, and eventually manufactured their own line of GPIB specific chips. Their current GPIB-USB product goes for $600 and they would like to sell you a full version of Labview for an additional $4K. Ouch !
6) Some amateurs (just having fun) create their own Propeller-based GPIB-USB controller (for less than $30 in parts). They offer at the OBEX plenty of great (and free) software for communication with a variety of GPIB instruments.
=========================
I've recently uncovered some old, old code (as in 1986 or so) with a wonderful breakdown of the exact sequence of bus command issued to perform most of the higher level GPIB operations. This is a veritable gold mine of logical detail.
In addition, I've been able to capture the DAV, NRFD, and NDAC line activity using my logic analyzer. The 3-way handshake is not nearly as complicated as an initial reading of the Source and Acceptor state machine description would suggest. Very straight forward.
All this suggests that the implementation of a GPIB propeller object is very doable. I'm working toward that end as time allows between projects. Hope to have something to offer on the OBEX in a few months.
I would like to demo the object by:
1) Instructing a Arbitrary Waveform Generator to output a specific waveform.
2) I then would like to capture this waveform using the oscilloscope.
3) Next, I would like to load my Arb Waveform Generator with the captured waveform
from the scope.
All the above could be done with a Propeller chip as the GPIB controller... and without PC control.
BradC, Thanks for suggesting this novel application for the propeller !! Thanks for posting your code. It's a great encouragement to know from the start that your code communicates with real GPIB instruments: a proof of concept.
That's excellent news!
Awesome!
www.thegleam.com/ke5fx/gpib/readme.htm
Rgds, David
Did you post source for this HPIB/GPIB object somewhere, ObEx for example.
Regards, David
Go back to the first page of this thread, look for the info outlined below and you will find the GPIB spin file attached:
Re: 12/2009 10:23 AM (GMT -4) Quote This PostIgnore Posts From BradC.Alert An Admin About This Post.
Ok, I just don't have the resources to put into this at the moment. Here is the bletcherous code I use for grabbing screendumps over GPIB from my Tek scope. It simply allows you to talk to a single GPIB as a master. I found my proto-board and fired it up. It works, so the code functions.
It's ugly, but it's a start and it works. There is no licensing info in the file. Take this post as releasing it as public domain.
lt's not particularly silly, is it?"
File Attachment :
GPIB.spin 3KB (text/plain)
GPIB is about to get used to let the P2 test itself, and log and analyze the results...
GPIB driver
It's able to communicate with every piece of antiquated equipment I had available to test with.
Image below show comms with a Keithley 6514 Electrometer, the electrometer is responding to a previous query, and then the Prop triggers another read.