IEEE 488 Controller Shield in Development

Hey Folks,

I have completed a proof of concept hack for a full-featured IEEE 488 shield that uses the MEGA2560 as the base platform. The circuit board used for the proof of concept came from some boards I have in stock from my former employer (unfortunately now closed) from one of our older IEEE 488 products.

I have seen other approaches that directly interface with the IEEE 488 bus. But having worked for many years with this bus and many instruments, using the recommended bus drivers saves on headaches down the road. Since a separate shield board is required for the IEEE488 connector, tossing the driver chips and a tiny bit of logic is pretty cheap insurance.

Anyway, the current proof of concept supports the essential IEEE 488 controller functions and uses a simple character command set to send and receive data, configure the controller’s various properties, etc. No IEEE 488 controller is used. It is a totally firmware-based implementation. So it is very inexpensive.

I am currently fleshing out some additional commands and adding Parallel Poll capabilities. I am also adding an alternate command set that will accept command words instead of characters, and the ability to store multiple device configurations in EEPROM.

I am also interested in not only selling just the shield and software library combination, but creating a couple of stand-alone products based on the MEGA-2560 open source design. The base product would connect to USB and the next level product would use Ethernet as the communication interface (no USB). The Ethernet version would use a simple Telnet connection, whereas the USB version uses any COM port terminal program.

In terms of validation, I have been using an IEEE 488 analyzer (also from my former employer) to ensure that the bus transaction timing and protocol is completely valid and within the IEEE 488-1978 spec. Raw data transfer speed is hitting at over 200 KBytes/Sec on the bus. But through the serial over USB interface, realistic limits would be 10 KBytes/Sec sustained. With some tweaking, I expect around 50 KBytes/Sec over Ethernet using the standard Ethernet Shield.

Surprisingly, the 200 KBytes/Sec rate does not use any interrupts on the IEEE 488 handshake lines. I am only using Timer3 and its interrupt function to handle timeouts. Direct port I/O and a careful approach to coding have cranked up that top speed. That has been more an exercise in how fast I could get it to go. But considering our fastest IEEE488 product ever ran at 1MByte/S using completely dedicated hardware, 200 KBytes/Sec isn’t bad for a bit-banged hack like this.

The reason why I decided to approach this design is that internally, in my business, I have several test cells and old test programs that require support for IEEE 488 instruments. I need to transition to newer computers, and IEEE488 plug in boards for PCIe are rare. There are a few USB and Ethernet to IEEE 488 converters out there. But quite frankly, they kind of suck. And I wanted to design my own.

A year or so ago I took the time to map out what pins would make the most sense to use for this project. But it has been a little under three weeks since I actually hacked the proof of concept, wrote the code, and wrote a bit of a user’s manual. That is a testament to the ease of use Arduino brings to the table when it comes to fast development. And the performance that I am seeing is also testament to using a fairly simple and not too convoluted environment. Sure, this can also be done on an embedded Linux platform. But I doubt that you would see 200KBytes/Sec, not using interrupts or an actual IEEE488 controller chip. And the cost of this implementation is pretty cheap!

Anyway, I’m looking for some feedback regarding interest in such a shield/library combination, as well as a simple, standalone product. After nearly 40 years, IEEE 488 is still out there, especially in situations where multiple instruments are needed to facilitate testing functionality. Sure, I’ve got HP34401A meters that have a serial port. But find me a computer that has a real serial port on it anymore! I’m able to run this controller on a Windows 10 PC with no issues whatsoever. And there are a ton of older HP instruments, as well as some stuff from other vendors, that still function quite well, that need IEEE 488.

Please feel free to ask any questions regarding this shield. I expect to be laying out the circuit board right after the beginning of the year. Once I have pricing on the PCB and a final BOM I’ll be able to determine pricing for the Shield version. I don’t plan on doing much with the standalone version until after the Shield version is complete and hopefully in the hands of some eager customers. But I would ballpark the Shield @ around $30 USD and a pre-programmed, uncased Shield and Mega-2560 at around $50 USD. Target price for an enclosed USB standalone unit is around $100 USD and an Ethernet version should hit about $150 USD. That at least gives some idea as to how this fits in with other, much more expensive products.

If you are a data acquisition geek and can identify my former employer from the IEEE 488 bus analyzer in the attached image, I’ll be impressed!

if you are a data acquisition geek and can identify my former employer from the IEEE 488 bus analyzer in the attached image, I'll be impressed!


Second thought IOTEC?

looks like IOTech to me.

It has been almost ten years since I worked extensively with GPIB. I have collected several test instruments that have GPIB, so I will keep an eye open.

I'm in the edu/research sector. I hate to use labVIEW as my only solution to GPIB devices. I would wager that your shield may have a niche market in my sector. If you could make GPIB devices over USB serial and have a working system that someone can use to acquire and log data, you may have a good chance. The alternative NI GPIB-USB is tied to NI LabVIEw to the death! Find a way that average tech-savy graduate students can use your product to collect and show data!

Yes, IOtech it is. Believe it or not I am still servicing some of those older products. It is done through the company that we were merged with after the acquisition by NI. But some of those old products are still alive and kicking.

Anyway, the coding is coming along nicely. This thing is turning into a fully-featured GPIB controller in its own right, with a number of good features. So it looks like the board layout will definitely take place in January.

As a simple shield, you would, of course, need to understand a bit about Arduino to use it. I can't really package things up into a pseudo-USB product since the required drivers, USB vendor and device ID all reference Arduino. So as a shield, it would, by necessity, only be useful to tech-savvy folks that can follow some fairly easy instructions. (i.e. purchase a Mega2560, download the Arduino IDE to get the drivers and the terminal program, load up the sketch or library, compile and download).

For now, a stand-alone USB product is not in the cards without paying a huge sum of money to get a vendor ID, or attempting to somehow obfuscate what I am doing. So, USB is only available to people that can do the tasks necessary to set up a Mega 2560, and know what they are getting is an Arduino-Based solution.

However, upon completion of the shield and finalization of the current code, I am going to jump right in to adding the Ethernet shield to the equation in order to create an Ethernet-based solution. That gets around the USB issue quite nicely. Especially since it will only require a Telnet client to control it. No proprietary software needed, no drivers required, still easy to use manually, or if you want to program, easy to connect and control through standard TCP/IP.

LabVIEW is just too much for something that should be so simple. And this needs to be kept simple!

Anyway, the other advantage of a complete product is that it would be enclosed and mechanically sound. That is important considering how bulky those GPIB cables can be. So there would be two products, the shield for people that know how to go that route, and the Ethernet to GPIB product.

Currently I am in the process of putting together a user manual in order to complete the definition of the command set. Roughly half of the commands are coded and running. The actual bus transfers are solid now, and no bus errors are taking place. GPIB handshaking and control line handling is not exactly a simple matter, and quite a bit of care, and a logic analyzer, have been used to verify that the timing is totally valid.

As far as acquiring data from a GPIB device, at the moment only ASCII transfers are coded. However, binary data transfer will be added before the shield version of the product is released. Once binary data transfers are supported, I can get some throughput testing complete. Definitely 10KBytes/Second is realistic for the shield-only version (14KBytes/Sec is the max at the 115,200 max baud rate.).

Ethernet should run at around 50 KBytes/Sec. That could be improved somewhat by tweaking some of the Ethernet code. Currently it is running polling and switching it to interrupts would make a big difference. That requires connecting a currently un-connected line on the Ethernet shield, but an actual product would have a dedicated PCB for all of the necessary components and not use existing shields. So modifying the communication scheme between the MEGA2560 and the WizNet chip would be much more practical.

I will post when the user manual is complete and available for a little constructive criticism. And if anyone is interested in getting their hands on a shield and perhaps a little product review, please let me know. I'd estimate shields being available towards the end of February if not sooner.

Russ Kessing
Unilytix LLC

What I would like to do is post the user manual once it is reasonably complete.

Project Update, 1-11-2016

With the addition of some resistors and some re-wiring of the interface connections I have reduced the number of required I/O pins by four. This change is necessary to ensure that the Ethernet Shield can operate correctly with the IEEE488 Controller Shield.

The user manual is about 60% complete and should be ready to post by the end of this week. At that time the board layout will begin. So I am still pushing for prototype boards to be in my hands in the month of February.

I have added binary data transfers to the product specification. These are only useful under program control, but for those that need them, it is good to have that capability. Binary transfers are limited to 128 bytes per binary input/output command. But you can perform as many of those commands as needed to read or write as much binary data as needed. This requirement is necessary because the Arduino serial over USB has no form of handshaking and this shield does not employ any large data buffers. But I think the implementation should not be a problem for just about any user.

Attached is an updated photo of the development system. It has been cleaned up quite a bit. Please note that the handful of components seen on the hack board will be replaced with surface mount equivalents. For simple development like this, through-hole is just easier to play around with.

Project Update 1-13-16

Although the current code for this shield does not support large buffers, I have taken a few days to design in large buffer (and other I/O) support before proceeding with the layout. The Mega2560 supports an external memory interface which can also do I/O. And I figured it wouldn't hurt to include that on the prototype shield board since there will be enough board space to allow me to validate the external memory interface design.

The primary use for this interface is to allow large SRAM buffers to be added to just about any design. Although the Mega2560 only has a 64K address space, my design supports up to 2 MBytes of addressable space using 32K pages. Changing pages is as simple as writing to a single I/O register on the board.

As many as 16 chips could be supported, although there are some practical electrical limits that would necessitate the use of buffering the address and data bus. That is not included in this initial design. But the chip select decoding is present so that part of the design can be validated.

Any special function IC with an 8 bit interface is also supported as long as it can work asynchronously (i.e. without a CPU reference clock). Simple latches and buffers are one example. And although the first revision of this shield won't use any of that, I can see a later revision that supports big buffers.

Supporting more than one device on the external memory bus, yet still providing 32K pages for any device requires that a device be 'selected' before reading or writing. Port L is used to select the specific device. Since a common requirement for a device needing big buffers is to read from I/O and write to memory, or read from memory and write to I/O, I've added a little additional logic that allows the board to automatically switch between two pre-selected devices on back to back I/O operations. It isn't as full featured as DMA, but for pennies worth of logic, it should simplify programming considerably.

The memory interface design should be completed today and then I will get back to the user manual. I still expect to post that by the end of the week, and then get on with the board layout. So prototype boards do look to be available sometime in February.