Everyone contemplating a test and measurement task is confronted with a choice: Which language is best for my application? Today’s market offers many choices of text-based languages and some graphical languages for test development. As a result, the selection of a language can have serious consequences for the success of the automated testing platform.
While at AT&T, we developed a series of tests for telecommunications lasers on Intel 8088-based PCs using Summit Software’s BetterBASIC. This platform worked well, and the debugged laser test code was a valuable asset.
However, this resource was lost when Summit Software decided not to migrate BetterBASIC to the next Windows PC architecture. Valuable engineering time had to be spent translating the debugged code to a new language that would be supported going forward.
Since debugged measurement software is such an asset, it makes sense to choose a language that is likely to still be around five to 10 years later. Purely proprietary languages like the old BetterBASIC may last for 10 years; however, your valuable debugged code is subject to the whim of the owners of the language. They may change the syntax to take the language in a new direction or discontinue it altogether.
In today’s world, a test and measurement language must do more than control hardware. It needs to parse eXtensible Markup Language (XML) messages and perform web transactions with other computers.
The IPC has proposed a set of standard XML-based messages for manufacturing equipment including test stations. Choosing a language that does not have built-in XML parsing capability would be shortsighted.
Java combined with the Java Native Interface (JNI) does not suffer from these pitfalls. Java is controlled by the Java Community Process (JCP), which decides the future of Java. The members of the JCP board include representatives from hundreds of companies that have a stake in the success of the language.
Java has found its way into many hardware architectures including PDAs and cell phones. It is capable of parsing XML, performing web transactions, and controlling hardware through JNI. Most likely, code written in Java will be viable 10 years from now.
Java is multiplatform. It runs on an abstraction called the virtual machine (VM). The VM is code written in C, which allows the same Java code to run on Windows, Linux, Solaris, or even a cell phone and PDA. The VM handles memory management, eliminating memory leaks, and permits the user interface to migrate over platforms without programmer intervention. C++ is the other most logical contender for multiplatform testing but lacks transportable graphical user interfaces (GUIs) and built-in memory management.
Although it is used widely for web development and certain embedded applications, test-hardware vendors have not offered much software support for Java. In the past, with slower processors, the overhead associated with the VM outweighed its benefits. However, in the last three years, the processor speed has tripled while the test instruments have not experienced the same gain in measurement speed.
Our measurement times have become limited by the instruments, not the test software. As a result, the benefits of using the VM outweigh the liabilities in all but the very most intense number-crunching applications.
One example is the large numbers of computations with complex numbers. Java has all the primitive data types you would expect, such as double and integer. However, there is no primitive type complex. This means Java classes must represent complex numbers.
Edwin Günthner, a graduate student at Karlsruhe University in Germany, modified the Java compiler code to include a primitive type complex for his thesis. Benchmarking of this compiler ran complex computations two to 21 times faster than using class-based implementations of complex numbers.
Sun’s website has an unfinished draft proposal, authored by Joseph Darcy and Michael Philippsen, on how to add complex numbers to Java. However, this proposal still is in the draft phase. If your application requires crunching large amounts of complex numbers, you still can get the multiplatform benefit using C99 and JNI to get the results into your Java application.
Selecting a Platform
Since Java is multiplatform, which platform is best? That depends on your application. If you are using instruments built to an open standard such as IEEE 488, then you can use any platform you wish.
Instruments built to communicate with an open standard allow the use of an open source. Linux is an open-source operating system well suited to test and measurement and handles multitasking. Its reputation for stability has earned Linux a large part of the server market. Finally, Linux does not require a licensing fee for each computer running it.
You can write Java in any text editor and compile from the command line. However, there are many development environments that also are open source. Some of them are available free for both commercial and personal use.
NetBeans is one such development environment. It has all the features you would expect. Pauses are inserted by clicking on the left margin with the mouse to insert a red dot. While paused in the debug mode, placing the mouse over the variable name will display the value. Method completion, a pop-up that shows the available methods after a keyword, is available and can be extended to classes you write yourself through the tools menu.
NetBeans is the open-source version of Sun One Studio. It does not have all the features a web developer would want, but it is just fine for hardware control. NetBeans is available from NetBeans.org and runs on Solaris, Windows, and Linux.
The JNI process is the key to benefiting from using Java for test and measurement. Sun’s website has a tutorial on JNI, and Robert Gordon’s book Essential JNI: Java Native Interface is an excellent resource.
An Example
Let’s look at a step-by-step example of JNI using a National Instruments (NI) GPIB-PCI card in a Linux PC. First, you will download the Linux drivers for the card from the NI website. The drivers will come in a tar.gz format. After unpacking the drivers, install them using the directions in the README file included with the drivers.
Let’s consider how you would access one of the NI 488 commands in Java. NI made the Linux drivers parallel the Windows drivers. The calls are the same. Remember, with the JNI process, the methods only return one object. For that reason, you must structure your calls to return only one object. If the underlying method in C returns more than one object, you must have a JNI method for each object to be returned from the C code.
Let’s take ibdev and ibonl examples. Communication with a device is opened using ibdev. You pass the GPIB address, end of string, and time-out variables, and ibdev returns an integer that you can use to access the device while using the other available commands.
The method ibonl places the device online or off-line. You now need to write a Java class that can call to the native method. You use the key word native. In this case, the method will be of the same name as the NI method in C language (Figure 1).
package nigpib;
public class javaGPIB {
public native int ibdev(int bdaddr, int praddr, int secaddr, int tmo, int eot, int eos);
public native int ibonl(int dev, int v);}
Figure 1. Java Class Code Example
After the Java source code is written, you compile it. In NetBeans, you select this from the menu, or you can use javac javaGPIB.java on the command line. The file javaGPIB.class is produced by the compiler.
For the next step, we need to go to the command line. Type javah -jni javaGPIB on the command line. This will produce a header file (Figure 2).
#include “jni.h”
#ifndef _Included_nigpib_javaGPIB
#define _Included_nigpib_javaGPIB
#ifdef __cplusplus
extern “C” {
#endif
JNIEXPORT jint JNICALL Java_nigpib_javaGPIB_ibdev
(JNIEnv *, jobject, jint, jint, jint, jint, jint, jint);
JNIEXPORT jint JNICALL Java_nigpib_javaGPIB_ibonl
(JNIEnv *, jobject, jint, jint);
#ifdef __cplusplus
}
#endif
#endif
Figure 2. Header File
Now, you write C code that has a method for each line of the header file. The corresponding C code is in Figure 3.
#include “nigpib_javaGPIB.h”
#include
#include
/* must link with cib.o for Linux*/
#include “ugpib.h” /* if using Linux */
/* must link gpib-32.obj for Windows*/
/*#include /*if using Windows */
/*#include “Decl-32.h” /*if using Windows */
void main(){
}
JNIEXPORT jint JNICALL
Java_nigpib_javaGPIB_ibdev(JNIEnv * env, jobject callingObj, jint boardaddr, jint primaddr, jint scndaddr, jint timout, jint eotx, jint eostr)
{
int dev;
dev=ibdev((int)boardaddr, (int)primaddr, (int)scndaddr, (int)timout, (int)eotx, (int)eostr);
return (jint) dev;
}
JNIEXPORT jint JNICALL
Java_nigpib_javaGPIB_ibonl(JNIEnv * env, jobject callingObj, jint dev, jint state)
{
int stat;
stat = ibonl((int)dev,(int)state);
return (jint) stat;
}
Figure 3. Corresponding C Code for Header File
Once you have written your C code, compile it on the command line linking it with the appropriate files. The C code compiles into a shared object. The file name is libnigpib_javaGPIB.so. You need to add a reference to the shared object in your Java source code just after the definition of the class javaGPIB. The line to be added is static {System.loadLibrary(“nigpib_javaGPIB”);}
Compile the new javaGPIB.java file, and you are ready to access GPIB instruments in Java running on Linux. You will have to use the Djava.library.path= option to inform the VM of the location of the library shared object.
The Java code you have just compiled also can run in Windows. However, you will need to replace the Linux file libnigpib_javaGPIB.so with a Windows DLL named nigpib_javaGPIB.dll. The Java code need not be changed for Windows, although the C code must include different header files and be linked with gpib-32.obj rather than cib.o. I used Visual C++ to compile the Windows DLL; however, the GNU C compiler can be used, but it is just a little more difficult.
Power of the Platform
This last point illustrates the power of a multiplatform approach. Suppose you need multiple GPIB-based stations for a high-volume product. You can automate the measurement in Java on Linux and avoid software licensing fees.
Now suppose a variant of the product is proposed for some of the test stations that will require the addition of a measurement with a PCI-based instrument that has no Linux driver. You can use JNI to gain access to the PCI-based instrument function calls just like we have done with the PCI-based GPIB card function calls. All the Java code you wrote for the operator interface, database interface, and data analysis would run on the new platform with no modifications.
By selecting Java, you can access hardware via JNI and get the security of the Java community protecting you against stranding valuable debugged test code in an obsolete language. By running your Java on Linux, you eliminate software licensing fees and gain stability. Lower costs, maximum code reuse, and system stability will all work together for the success of your test and measurement effort.
Author’s Note
The code presented in this article has worked on both Linux and Windows operating systems; however, a number of naming and location conventions on both the Java and Windows DLL side need to align. Should you experience difficulties when running the code, this is a likely area to examine.
About the Author
Roy Timpe has 20 years experience in test and measurement, starting with AT&T and continuing through Lucent Technologies. He has a patent with Agere Systems on an algorithm used in testing GaAs integrated circuits. More recently, he has been with Agility Communications and is consulting in the test and measurement field. Test Consulting, 366 Blandon Meadows Pkwy., Blandon, PA 19510, 610-926-5989, e-mail: [email protected]
Return to EE Home Page
Published by EE-Evaluation Engineering
All contents © 2003 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
June 2003