Sunday, December 14, 2014

Installing an HP OEM Windows 2012 R2 Essential server as KVM Guest


I have an HP Proliant DL385p Gen8 box together with a HP/OEM installation disk of Windows Server 2012 R2 Essential.
On the iron I've installed Ubuntu Server 12.04.5 64bit plus xfce 4.1 (horrible: avoid it!) and KVM latest version available in ubuntu repository at the time of this writing (Dec2014).
The windows server is going to run as a guest over KVM. I have plenty of configurations like this perfectly working where, however, the Windows software is not OEM..
Here, a little while after the windows server installation CD boots up in the guest, it stops with the following message:"This system is not a supported platform": the hardware platform must be an HP and the actual one is not. No way.

HP supports this scenario (http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c00970200) suggesting ways for the hypervisor to pass BIOS and System information from host hardware to guests. Unfortunately KVM is not included...
Reading the redhat documentation (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sect-smbios-sys-info.html) helped in finding a solution:
First you need to dump the HP BIOS information by running the “dmidecode“ command, to retrieve the information you need:
# dmidecode 2.11
 SMBIOS 2.6 present.
 35 structures occupying 1145 bytes.
 Table at 0x000FB330.
Handle 0x0000, DMI type 0, 24 bytes
 BIOS Information
 Vendor: HP
 Version: A28
 Release Date: 07/12/2014
 ....
 Handle 0x0001, DMI type 1, 27 bytes
 System Information
 Manufacturer: HP
 Product Name: Proliant DL385p Gen8
 Version:
 Serial Number: 099999AB
 UUID: 1A3FD5918-FA32-56B3-8000-3A5C8B66F003
 Wake-up Type: Power Switch
 SKU Number: 947382-432
 Family:
 ...
Now just open your Guest XML file (in /etc/libvirt/qemu/) and, as per redhat instructions, into <os> tag add:
<smbios mode="sysinfo">
and then, somewhere into <domain> tag add this, with values from dmidecode output:

<sysinfo type='smbios'>
 <bios>
  <entry name='vendor'>HP</entry>
 </bios>
 <system>
  <entry name='manufacturer'>HP</entry>
  <entry name='product'>Proliant DL385p Gen8</entry>
  <entry name='serial'>099999AB</entry>
  <entry name='sku'>947382-432</entry>
  <entry name='UUID'>1A3FD5918-FA32-56B3-8000-3A5C8B66F003</entry>
 </system>
</sysinfo>
And that’s all, folks! Now just start your Guest and the Windows Server  installation should pass the HP hardware check. Please note that Windows 2008 didn't need the UUID field.

Monday, March 3, 2014

ARDUINO UNO as a USB to GPIB controller - version 6.1


TEK2232 loves Arduino
TEK2232 loves Arduino
Fluke PM2534 loves Arduino
Fluke PM2534 loves Arduino

Disclaimer:
This program is provided as is. It is a hobby work.
It doesn't work correctly. It has not been tested. It can damage your Arduino and the device you connect it to.
Can have unexpected behaviors, can get stuck at any moment, can read and write data to/from the device in ways you might not expect. It can send wrong or erratic commands to the device. Can display data that differ from the actual data the device sent out. Can address GPIB devices
differently from what you might expect.
I have not conducted any speed test; the maximum speed supported is simply unknown.
Is does not follow any official standard. Only a minimum set of the functions included in IEEE-488 is barely emulated.
Hardware limitations: the lack of a GPIB line driver has two major implications: first: your Arduino is directly connected to the device GPIB port without any form of electrical protection of buffering - this can potentially damage your Arduino and/or your device; second: what can happen if you connect more than one GPIB device to the BUS is unpredictable both from an hardware and software point of view. I only experimented with a single GPIB device connected to the BUS.

Creative Commons License
Arduino USB to GPIB firmware by E. Girlando is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Permissions beyond the scope of this license may be available at mailto:emanuele_girlando@yahoo.com.

After nights spent coding, this post is about version 6.1 of my USB to GPIB controller software for ARDUINO UNO.
Version 6.1 ??!! Yes, that's it! This is actually version 2 of my software, but because some third party software - actually KE5FX GPIB toolkit -  relies on the content of the output string as issued by the "++ver" command to work properly, I had to force the string "version 6." as part of the" ++ ver" command output. So .. this version has become version 6.1. 

Version 1.0 has been presented in this related post.
Version 1.0 was very crude. Most a beta version to verify the feasibility of this project.
I want to thank you very much all of you that provided me feedbacks.

This release represents a significant step forward toward "++" commands compatibility and software robustness. Still the software is aimed for those of you with test instruments interest at hobby professional level. Do not use it in professional environments.

release notes version 6.1:
  • bug fix especially at command interpreter level ;
  • command syntax is now compatible with the "++" language;
  • for compatibility reasons the controller is now much more silent when executing commands (but see the "++verbose" command below);
  • reads from GPIB are not buffered anymore: char received from GPIb are sent to USB a soon as they are received. This enable this version of the controller to receive bulk binary data;
  • for compatibility reasons the escape char has been changed from "\" to Ascii ESC (0x1B);
  • "++addr" has a new default value of 2;
  • "++eot_char" and "++eot_enable" commands have been implemented with default values of 10 (0xA) and 0 respectively;
  • "++auto" is no more a toggle and is fully compatible now. The new syntax is "++auto [0|1]" and the default is 0;
  • "++eoi" has been implemented with syntax "++eoi [0|1]" and a default value of 1;
  • "++eos" has been implemented with syntax "++eos [0|1|2|3"] and a default value is 1;
  • "++read" is completely unbuffered now. It terminates in front of an EOI signal detect OR an EOS char received from GPIB.  "++read eoi" changes this logic to EOI detection only. This is useful (and works) for binary transfers - e.g. screen dumps. 
  • "++ver" returns " the string "ARDUINO GPIB firmware by E. Girlando Version 6.1 ".
  • "++read_tmo_ms" has been implemented with syntax "++read_tmo-ms [100-9999]" and a default value of 200;
 Two additional proprietary commands (not usually included in the "++" set) have been implemented:
  • "++verbose" this command toggles the controller between  verbose and silent mode. When in verbose mode the controller assumes an human is working on the session: a ">" prompt is issued to the USB side of the session every time the controller is ready to accept a new command and most of the "++" commands now print a useful feedback answers (i.g. the new set value or error messages). This breaks the full "++" compatibility. Do not use verbose mode when trying to use third party software. Default is verbose OFF.
  • "++dcl" sends an unaddressed DCL (Universal Device Clear) command to the GPIB. It is a message to the device rather than to its interface. So it is left to the device how to react on a DCL. Typically it generates a power on reset.
This version of the controller successfully reacts to the Prologic.exe program included in the KE5FX GPIB toolkit. I was not able to test the 7470.exe program as I do not have any instrument compatible with the toolkit (I indeed tryed with my TEK 2232 scope, but it failed...).

The full project documentation updated to version 6.1 follows.
----

ARDUINO UNO as a USB to GPIB controller 

Documentation of Version 6.1

Introduction 

This project is aimed to provide a cheap and quick GPIB solution for those that need to gain control over a single instrument and interact with it (e.g. to dumo screen shots or calibrate instruments that can be calibrated via GPIB only -- HP6632A Power Supply being a good example).

I supposed that cheap adapters were available on the market to interface GPIB instruments with a PC. I was wrong. The only feasible solution is to go with a Prologix USB to GPIB converter, still it would have cost me more than 100 EUR .
Other solutions (open or proprietary) required buying or building hardware.

On the other end I had an Arduino UNO floating around on my bench waiting for a problem to solve other than blinking leds or writing "hello world" on an LCD..

So I decided to face the challenge of writing down a sketch and have the Arduino play the adapter role I was looking for.
To make a long story short.. (I supposed that GPIB was simple at least as much RS-232 is, .. and it is not! I was wrong again!) after reading a lot of IEEE-488 documentation, I got a decent implementation of a GPIB controller out of my Arduino UNO. This post is dedicated to describe the project.


Code availability

I some of the feedbacks post in the HP or TEK Yahoo discussion groups I was accused of not having published the source code. Here it is. Enjoy it! BUT: I am interested in test instruments. I am not interested in developing open source projects. I wrote this program just because I am an ICT professional and consequently I have some educational reminiscence of  programming.

Because of the hard effort I put on the project, I kindly request you to donate a couple of bucks if you find this program useful for your hobby.



  Download GPIB6.1.ino (dropbox link).
donations are not for a "product" or a "product functionality", .. they represent a light payback for what you have learned reading a content and possibly getting some free software to play with... which have cost some effort to the editor to be developed.

Below you'll find the program documentation describing the implemented functionalities, limitations, commands syntax and hardware required (close to null.., just a bunch of wires and a plug).

----
This program allows to have the Arduino UNO to implement a GPIB controller. The objective was to have a way to get control of test instruments by the ability to send and receive commands to/from such devices via GPIB using a terminal emulator o an appropriate script.

Despite the disclamer I can say that the objective has been successfully met; with this program uploaded to an Arduino UNO I can now create sessions with my hobby  instruments and interact with them the way they allow too do (see instrument manual).
Most of the version 1 limitations are still here. Actual limitations are:

- the program operates in controller mode only; it is not (yet) able to behave like a device.
- two important GPIB pins are not managed: REN and SRQ;
- Serial poll is not implemented.
- subaddressing is not implemented.
- ++read [char] not implemented (useful?!);
- ++rst, ++lon, ++savecfg, ++spoll, ++srq, ++status, ++help are not implemented;

Hardware set up instructions:

The hardware needed is simple: just a bunch of wires from the GPIB plug to Arduino pins. Here is the pin mapping:

GPIB-Arduino fixture
GPIB-Arduino fixture
  A0   GPIB 1
  A1   GPIB 2

  A2   GPIB 3 
  A3   GPIB 4
  A4   GPIB 13
  A5   GPIB 14
  4    GPIB 15
  5    GPIB 16
  12   GPIB 5
  11   GPIB 6
  10   GPIB 7
  9    GPIB 8
  8    GPIB 9
  7    GPIB 11




NOTE:
 GPIB pins 10, 17-24 goto GND, but (!!):
  •  GPIB pin 17 (REN) has to be implemented ..stay ready to reroute it differently in the future;
  •  GPIB pin 10 (SRQ) has to be implemented ..stay ready to reroute it differently in the future;
  •  GPIB pin 12 should be connected to the cable shield (not used here - I left it n/c).
Build the the shield the way you want. Nothing is simpler provided you have a minimum electronic construction skills.
For testing I preferred the "flying" shield visible in the pictures but the actual construction is your choice.
The male GPIB connector was realized sacrificing a CENTRONICS 32pins male connector out of a PC parallel printer cable. I have just cut it leaving 12 positions out of the original 16.

Get it working

Get the GPIB6.1.ino sketch compile it and upload it to the Arduino.
If you want/need to see a bunch of debugging output, just uncomment the two #defines directives on top of the source file.

Get any terminal emulator and manage to have it working with the FTDI RS232/USB converter (nothing to do under linux; install the FTDI driver in Windows: it cames for free with the Arduino IDE. I have successfully used the serial display provided by the arduino IDE, putty under Linux and HyperTerminal under (virtual) Windows XP.
You probably have to set the some serial communication parameters.
The default serial speed is 115200 bps.
Other serial parameters are: Data_bits=8, Stop_bits=1, Parity=None, Flow_control=None.
I successfully also interacted with the controller using cat, tail -f, echo, .. linux commands redirected to the FTDI serial device (/dev/ttyACM0 in my case). To do that you have to play a little with the stty command. For sure you need to set -hupcl so that the DTR 232 signal is not deasserted while disconnecting from the device. It can also be useful to defeat the "reboot on connection" feature of the Arduino. Google about these topics before doing it! You can make your arduino impossible to reprogram.
The controller is silent at startup. To test it send a "++ver" command and the Arduino should reply with "ARDUINO GPIB firmware by E. Girlando Version 6.1".
If you plan to interact directly with your instrument, please issue the command "++verbose". This will make your controller much more friendly (see below).

Principle of operations

Everything received from the USB is passed to GPIB (126 char max).
Characters from the USB are fetched in line by line and buffered. The software support for both CR, LF and CRLF line termination.
Once the line termination char is encountered in the USB input stream the entire buffer gets parsed. If you need to include CR or LF in the input stream to be sent to your instrument you must rely on the help of the linux serial device driver using ^V in front of ^M or ^J to defeat their default behaviour of terminating the command shell lines.. (see stty man page). Still the ^V mechanism is not enough. ^V prevents the linux driver from sending out your line in the middle of your editing, but still the received CR or LF are interpreted as end of line by the Arduino. To avoid this an escape mechanism has been implemented. The escape char is "ESC" or 0x1B. So to send CR to the GPIB BUS you need to type "ESC^V^M" and similarly for LF. To send a single "ESC" you must escape it with "ESC" so you need to type "ESC" two times. You can terminate the input line with "\" so that the following CR or LF will be escaped. If you insert unescaped CR or LF in the stream (e.g typing "^V^M" with no preceding "ESC") the line is split in two parts: everything preceding the CR or LF is passed on for processing; everything following the CR or LF is simply discarded.
I don't know of any way to send CR or LF or ESC ascii char from the Arduino IDE serial monitor. Testing for all this stuff has been conducted via putty.
WARNING: if you use buffered I/O on the sender side, and you often do, be aware that sending more than 64 chars per line can lead to serial buffer overflow as the Arduino sketch cannot keep pace with the burst of characters coming in @115200bps. Yet, the program detects this situation, issues a "Serial buffer overflow - line discarded. Try setting non buffered I/O" error message and discards the line entirely. As the error message suggests, you can switch your sender (terminal emulator) to unbuffered I/O so that it sends out one char at a time. If you are typing at a keyboard the problem is solved (unless you are typing at the speed of light); if the data comes from some kind of script, care must be taken to send small chunks of data introducing delays to allow for the program to eat them.
Line starting with "++" are assumed to be commands directed to the controller and are parsed as such. Nothing beginning with "++" can be sent to instruments.
Everything not starting with "++" is sent to the addressed instrument over the GPIB BUS.

Implemented commands:

NOTE: the command interpreter is very raw: I remember from high school that they have to be programmed in a certain way, but I don't really remember how; so I did my best. Misspelled commands will (better: should) generate a Syntax error message. As soon as a non existent command code or a Syntax error is detected the line is discarded entirely. After a valid command has been recognized, any additional characters following it (if any) is discarded.

++addr [address] 
Fully compatible with the "++" de facto standard, but subaddressing is not implemented (SADs are syntactically accepted but ignored).
++ver
just displays a version string of the controller.
++auto
Fully compatible with the "++" de facto standard.
But what is automode? Ok, you have to know that GPIB devices do not work the way we are used to with modern devices. When you send a command they process it and if any output is generated they put it to an instrnal buffer waiting to be addressed to speak. The final result is that just to get the identification string out of a device you have to send the request command (e.g "id?") and then issue the command "++read" to the controller. Automode ON just makes this for you: for every string sent to GPIB, the controller issues an implicit "++read" to the addressed device. This gives you the impression to have the device immediately react in front of the string you sent it. Beautiful! ...however a hidden trap is around: some GPIB device gets upset if asked to speak when it has nothing to say and with automode ON this can happen very often (I have an instrument that lights the error annunciator on the front panel when this situation occurs, but yet it continues working as nothing happened).
For this reason automode is blocked if you just send an empty string pressing CR or NL. Automode is also suppressed with "++" commands.
++clr
Fully compatible with the "++" de facto standard.
++eoi
Fully compatible with the "++" de facto standard.
++eos
Fully compatible with the "++" de facto standard.
++eot_enable
Fully compatible with the "++" de facto standard.
++eot_char
Fully compatible with the "++" de facto standard.
++ifc
Fully compatible with the "++" de facto standard.
++llo
Fully compatible with the "++" de facto standard.
++loc
Fully compatible with the "++" de facto standard.
++mode
the command is syntactically fully compatible, but the only mode implemented is CONTROLLER; so the cammand is provided for compatibility but it is inoperative.

++read
Fully compatible with the "++" de facto standard, but ++read [char] is not implemented.
++read_tmo_ms
Fully compatible with the "++" de facto standard.
++trg
is implemented for the addressed device only; it doesn't accept PADs or SADs paramenters.

++rst, ++lon, ++savecfg, ++spoll, ++srq, ++status, ++help are not implemented.

Two additional proprietary commands (not usually included in the "++" set) have been implemented:
++verbose
This command toggles the controller between  verbose and silent mode. When in verbose mode the controller assumes an human is working on the session: a ">" prompt is issued to the USB side of the session every time the controller is ready to accept a new command and most of the "++" commands now print a useful feedback answers (i.g. the new set value or error messages).
This breaks the full "++" compatibility. Do not use verbose mode when trying to use third party software. Default is verbose OFF.
This is very useful to see timeout errors otherwise hidden..
++dcl
Sends an unaddressed DCL (Universal Device Clear) command to the GPIB. It is a message to the instrument rather than to its interface. So it is left to the instrument how to react on a DCL. Typically it generates a power on reset. See instrument documentation.

Feedbacks

This version can be successfully used to interact with your instruments, but is still imperfect. Please post feedbacks and comments below this post.
In addiction to bug fixing, I am interested in sharing experiences in using third party software especially for dumping plots down from instruments. I have a TEK2232 and an HP853 I am interested in producing plots from.


Future development

I am going to improve it by bug fixing and keep the documentation deep and updated and working on Version 6.2 that will wide the project scope up to:
  • settings save/restore,
  • serial poll support (if not too difficult),
  • improve ++trg compatibility,
  • porting to different Arduino platforms.

Conclusions

Enjoy you GPIB controller and please do not forget to donate some buck just to recognize the effort I made to develop and document this project.
Thank you!
Emanuele.



  Download GPIB6.1.ino (dropboxlink).
donations are not for a "product" or a "product functionality", .. they represent a light payback for what you have learned reading a content and possibly getting some free software to play with... which have cost some effort to the editor to be developed. 

Creative Commons License
Arduino USB to GPIB firmware by E. Girlando is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Permissions beyond the scope of this license may be available at mailto:emanuele_girlando@yahoo.com.

Wednesday, February 5, 2014

Arduino UNO as a USB to GPIB adapter / controller


NOTE:
This version is OBSOLETE!! Please go to this post for the 6.1 release software and documentation.
---

Version 1 of this project is aimed to provide a cheap and quick GPIB solution to those that need to gain control over a single instrument and interact with it (e.g. to calibrate instruments that can be calibrated by GPIB only -- 6632A Power Supply being a good example).

I supposed that cheap adapters were available on the market to interface GPIB instruments with a PC. I was wrong. The only feasible solution is to go with a Prologix USB to GPIB converter, still it would have cost me some tens of bucks.
Other solutions required buying or building hardware.

On the other end I had an Arduino UNO floating around on my bench waiting for a problem to solve other than blinking leds or writing "hello world" on an LCD..

So I decided to face the challenge of writing down a c++ program and have the Arduino play the adapter role I was looking for.
To make a long story short.. (I supposed that GPIB was simple at least as much RS-232 is, .. and it is not! I was wrong again!) after reading a lot of IEEE-488 documentation and giving a try to a similar program I found over the internet, I got a decent implementation of a GPIB controller out of my Arduino UNO. This post is dedicated to describe the project.

Because of the hard effort I put on the project, I kindly request you to donate a couple of bucks if you find this program useful for your hobby.




Download GPIB1_0.hex file by right click and save link as..

Below you'll find the program documentation describing the implemented functionalities, limitations, commands syntax and hardware required (close to null.., just a bunch of wires and a plug).

====

Disclaimer:
This program is provided as is. It is a hobby work.
It doesn't work correctly. It has not been tested. It can damage your Arduino and the device you connect it to.
Can have unexpected behaviors, can get stuck at any moment, can read and write data to/from the device in ways you might not expect. It can send wrong or erratic commands to the device. Can display data that differ from the actual data the device sent out. Can address GPIB devices
differently from what you might expect.
I have not conducted any speed test; the maximum speed supported is simply unknown.
Is does not follow any official standard. Only a minimum set of the functions included in IEEE-488 is barely emulated.
Hardware limitations: the lack of a GPIB line driver has two major implications: first: your Arduino is directly connected to the device GPIB port without any form of electrical protection of buffering - this can potentially damage your Arduino and/or your device; second: what can happen if you connect more than one GPIB device to the BUS is unpredictable both from an hardware and software point of view. I only experimented with a single GPIB device connected to the BUS.


This program is inspired  by a similar job done by IW3IIF who started from what he has found at
http://www.bananawani-mc.blogspot.fr.

----

Introduction

This program is an attempt to have the Arduino to implement a GPIB controller. The objective was to have a way to get control of test instruments to send and receive commands to/from such devices via GPIB.
Future implementation may include binary data transfer mainly aimed to get plot data out of test instruments like oscilloscopes or spectrum analysers.
This is version 1.0. As everybody knows nobody should trust version 1 subversion 0 of any program... but that's it. Give it a try.
Despite the disclaimer I can say that the objective has been successfully met; with this program uploaded to an Arduino UNO I can now control my hobby lab GPIB instruments and even calibrated some of them. I hope it can work with yours as well.
There are a bunch of actual limitations:
- the program operates in controller mode only; it is not (yet) able to behave like a device.
- two important GPIB pins are not correctly managed: REN and SRQ.
- Serial poll is not implemented.
- subaddressing is not implemented.
- only ASCII transfer have been tested. It shouldn't be too difficult for me to implement binary transfers in version 2...

Hardware set up instructions:

The hardware needed is simple: just a bunch of wires from the GPIB plug to Arduino pins. Here is the pin mapping:

  A0   GPIB 1
  A1   GPIB 2

  A2   GPIB 3 
  A3   GPIB 4
  A4   GPIB 13
  A5   GPIB 14
  4    GPIB 15
  5    GPIB 16
  12   GPIB 5
  11   GPIB 6
  10   GPIB 7
  9    GPIB 8
  8    GPIB 9
  7    GPIB 11


NOTE:
 GPIB pins 10, 17-24 goto GND, but:
  •  GPIB pin 17 (REN) has to be investigated further ..stay ready to reroute it differently in the future;
  •  GPIB pin 10 (SRQ) has to be investigated further ..stay ready to reroute it differently in the future;
  •  GPIB pin 12 should be connected to the cable shield (not used here - I left it n/c).
Build the the shield the way you want. Nothing is simpler provided you have a minimum electronic construction skills.
For testing I preferred the "flying" shield visible in the pictures but the actual construction is your choice.
The male GPIB connector was realized sacrificing a CENTRONICS 32pins male connector out of a PC parallel printer cable. I have just cut it leaving 12 positions out of the original 16.

Get it working

Get any terminal emulator and manage to have it working with the FTDI RS232/USB converter (nothing to do in linux/UNIX; install the driver in Windows). I have tryed it with the serial display provided by the arduino IDE and putty under Linux. Nothing let me suspect it shouldn't work with HyperTerminal under Windows or similar programs. Just give it a try.
You probably have to set the some serial communication parameters.
The default serial speed is 115200 bps.
Other serial parameters are: Data_bits=8, Stop_bits=1, Parity=None, Flow_control=None.
If everything is working you should have the Arduino output the welcome message: "I am a GPIB controller now" followed by the ">" prompt.

Principle of operations

Everything received from the USB is passed to GPIB (131 char max).
Characters are fetched in one by one and buffered; at the moment only ascii transfer is supported, so you can send command to the device. The software support for both CR, LF and CRLF line termination. Once the line termination char is encountered in the USB input stream the entire buffer gets parsed. If you need to include CR or LF in the input stream you must rely on the help of the linux serial device driver using ^V in front of ^M or ^J (see stty manual). Still the ^V mechanism is not enough. ^V prevents the linux driver from sending out your line, but still the received CR or LF are interpreted as end of line by the Arduino. To avoid this an escape mechanism has been implemented. The escape char is "\". So to send CR to the BUS you need to write "\^V^M" and similarly for LF. To send a single "\" you must escape it with "\" so you need to send "\\". In the Arduino serial monitor you can terminate the input line with "\" so that the following CR or LF will be escaped. If you insert unescaped CR or LF in the stream (e.g with "^V^M" sequence with no preceding "\") the line is split in two parts: everything preceding the CR or LF is passed on for processing; everything following the CR or LF is simply discarded.
WARNING: if you use buffered I/O on the sender side, and you often do, be aware that sending more than 64 chars per line can lead to serial buffer overflow as my program cannot keep pace with the burst of characters coming in @115200bps. Yet, the program detects this situation, issues a "Serial buffer overflow - line discarded. Try setting non buffered I/O" message and discards the line entirely. As the error message suggests, you can switch you sender (terminal emulator) to unbuffered I/O so that it sends out one char at a time. If you are typing at a keyboard the problem is solved (unless you are typing at the speed of light); if the data comes from some kind of script, care must be taken to send small chunks of data introducing delays to allow for the program to eat them.

Implemented commands:

NOTE: the command interpreter is very raw: I remember from high school that they have to be programmed in a certain way, but I don't really remember how; so I did my best. Misspelled commands will (better: should) generate a Syntax error message. As soon a Syntax error is detected the line is discarded entirely. After a valid command has been recognised, any additional characters following it (if any) is discarded.

++addr [address] 
address can be any number between 1 and 31.
Without any parameters it displays the current setting of the address stored within the Arduino and used to address any communication (read or write).
If address is present the command will set the address to the specified number.
Any character after a valid command is discarded, so "++addr 4 fakechars" will change addr to 4 and "fakechars" is discarded. "++addr 4s" will also change addr to 4 and the leading "s" is discarded.
The addr parameter can start with "0" so "++addr 03" is a valid command.

++ver
just displays a version number of the controller

++auto
just toggle between auotomode ON and automode OFF. Default is OFF.
But what is automode? Ok, you have to know that GPIB devices do not work the way we are used to with modern devices. When you send a command they process it and if any output is generated they put it to a buffer waiting to be addressed to speak. The final result is that just to get the identification string out of a device you have to send the request command (e.g "id?") and then issue the command "++read" to the controller. Automode ON just makes this for you: for every string sent to GPIB, the controller issues an implicit "++read" to the addressed device. This gives you the impression to have the device immediately react in front of the string you sent it. Beautiful! ...however a hidden trap is around: some GPIB device gets upset if asked to speak when it has nothing to say and with automode ON this can happen very often (e.g. if you just press CR, an empty string is processed and, because of automode ON, the device is immediately asked to speak, even if nothing has been sent to it). I have a device that lights the error annunciator on the front panel when this situation occurs, but yet it continues working as nothing happened.

++read
Asks the currently addressed device to speak. Everything received is sent upstream to the USB. The stream is buffered (132 chars max) and this is the limitation preventing me to implement bulk binary transfers. V2 will try to overcome this issue.
If automode is ON issuing the "++read" command causes TWO reads in rapid succession. This is not always welcome by GPIB devices...

++clr
Sends a SDC command to addressed device. Reaction to this command is device dependent, but all the devices I know about react with a power on reset at least at GPIB interface level.

++ifc
Sends a (universal) DCL to the BUS. This is a BUS command sent to the BUS and not to a single devices. Reaction to this command is device dependent, but all the devices I know about react with a power on reset.

++eos [mode]
mode can be any number between 1 and 3. Default is eos=1.
Without any parameters it displays the current setting of the eos;
mode=0 means that the controller will send CRLF as the last character in the stream sent to GPIB;
mode=1 means that the controller will send CR as the last character in the stream sent to GPIB;
mode=2 means that the controller will send LF as the last character in the stream sent to GPIB;
mode=3 means that the controller will not send any special char as the last character in the stream sent to GPIB;
In any case, when transmitting the last character, the controller asserts the EOI GPIB line, a line most devices are able to manage.
The command syntax follows the same rules of the +addr command.

How to upload  the HEX file to your Arduino

I learned how to do an HEX upload to Arduino reading a post on the Arduino official forum (http://forum.arduino.cc/index.php?topic=120286.0).

The idea is to use the same command the IDE uses to upload just compiled files.
Assuming you have the IDE correctly setup and up and runing, you need to do the following:

  • in the Arduino IDE select File-> preferences and check the "Show verbose output during -> upload" checkbox;
  • compile a simple example sketch (e.g blink.ino is ok);
  • look at the IDE output and examine the "avrdude" command (the actual upload program used by the Arduino IDE);
  • use exactly the same command to upload the GPIB1_0.hex file.

Here is the command that works for me (everything in fixed font goes on a single line):
/home/emanuele/arduino-1.0.5/hardware/tools/avrdude -C/home/emanuele/arduino-1.0.5/hardware/tools/avrdude.conf -v -patmega328p -carduino -P/dev/ttyACM0 -b115200 -D -Uflash:w:/home/emanuele/sketchbook/GPIB/GPIB.hex:i
A short explanation:

-C/home/emanuele../../avrdude.conf -> configuration file
-v -> verbose; you can omit it or add more (e.g. -v -v -v) to get more output
-patmega328p -> partnumber atmega328p
-carduino -> programmer is arduino
-P/dev/ttyACM0 -> the serial port your arduino is connected to
-b115200 -> baud rate - upload speed
-D -> diasables erasing
-Uflash:w  -> Write to Flash memory
/home/emanuele/sketchbook/GPIB/GPIB.hex  -> path and file name to the hex file
:i   -> optional, indicates an Intel hexfile

Feedbacks

With version one what I am interested in is to have somebody give it a try and report me feedbacks like:
my instrument times out often,
this input string doesn't work as expected,
my instrument gets stuck when ... ,
etc. etc. ...

Future development

I am going to improve it by bug fixing and keep the documentation deep and updated and working on Version 2 that will wide the project scope up to:
  • device mode to accept binary transfers (aimed to screen plots),
  • a closer  "++" compatibility,
  • settings save/restore,
  • serial poll support (if not too difficult),
  • porting to smaller Arduino platforms.

Conclusions

Enjoy you GPIB controller and do not forget to donate some buck just to recognize the effort I made to develop and document this project.
Thank you!
Emanuele.




Download GPIB1_0.hex file by right click and save link as..