SDK—Not Just Another Pretty Acronym

Let’s face it. The world of high tech continues to change the rules. We understand that we should continue to expect better features at lower prices. And we intrinsically understand that every 18 months we should expect a new generation of product.

But what we may not understand is how new products-far more complicated than the generation they replace-can be created in the shorter time cycles that we have come to expect. The answer is known to many system designers as SDKs or software development kits.

In the past, designers chose hardware components from a catalog and then plugged them together like Legosr to create the system they wanted. Today, designers select complete board-level subsystems designed to work in an open architecture like the PC. With SDKs, they couple operating systems and application/driver software to interconnect the subsystems that they have selected.

Subsystems allow designers to select a catalog product that meets the required performance parameters. This obviates the need for a thorough understanding of the myriad of devices, bus details, timing, addressing, and other interface issues that would be required for them to build the subsystem themselves. A simple purchase brings the expertise of a team of designers in one pretested package.

But even after the hardware has been selected, the product is not complete. There is the task of customizing the hardware through the creation of drivers and application software to provide the features that each new product requires.

Requiring Additional Software

For application software, generally there is a pool of existing code that may need to be updated to include new features. Most companies have this capability in-house. However, linking purchased board-level subsystems to applications software is another matter.

Creating the interconnect software (drivers) and commands to use board-level subsystem features can be a daunting task. It requires an understanding of hardware devices, their interface and control structures, command formats, timing details, and bus interface information. The information is available, and gathering it is easy. Using it is not.

There are varying approaches to creating the additional software required to use board-level products. Certainly the oldest and most painful method involves writing software drivers and command structures from scratch, an approach that demands intense attention to every detail of the hardware. It requires a thorough understanding of every device interface, detailed timing considerations, bus structures, command and status register information, and virtually every facet of every device for which the software is being written. Forgetting to initialize even a single register may result in the overall system working improperly.

You can expect to spend seemingly endless hours troubleshooting and debugging systems designed this way. But there is at least one clear benefit: Upon completion of the task, the designer will have a thorough understanding of the operation of every part of the system. Of course, should a change in hardware be required, the designer can expect to restart the entire process.

Another approach to interfacing subsystems is to purchase prewritten or canned software. There are suppliers of operating software for most typical applications. Because purchased software and hardware are designed to operate together, interfacing the required board-level subsystems is easy.

But there are several disadvantages. If the software does not provide the exact functions required, adding new or different functions may be extremely difficult. Likewise, if a single manufacturer does not supply the entire suite of hardware subsystems for a project, it can be difficult to integrate software from multiple vendors.

Enter the SDK

There is a better solution. Most data acquisition hardware manufacturers offer some type of access to the hardware drivers, usually referred to as SDKs. These types of products also are known as libraries or tool kits. They were created to provide designers with a complete understanding of hardware subsystem design details and yet allow them to develop new applications quickly and efficiently.

SDKs are libraries of functions used to speed up the design process when implementing board-level subsystems. The libraries are created by the board designers and tuned to the specific hardware detail of the boards for which they are written. As a result, they take full advantage of board capabilities while freeing the system designer from needing to know specific hardware details.

For example, most board-level products must be initialized to a known state when power is first applied. This may include clearing buffers and memory locations, setting multiple registers to specific values, setting or clearing flags, and sending initialization commands.

With an SDK, a library command such as INITIALIZE is supplied. Without such a command, a system designer must know about each memory location, register, and flag as well as the addresses and procedures needed to initialize them. With a single INITIALIZE command from the library, the entire process is completed. To make things even easier, the same command exists for every product that a vendor supplies.

SDKs are designed for use with Windows 95, 98, NT, and UNIX and include library routines for all of them. Without the kit, the designer would have to write code to interface to each operating system.

Speeding Up Development

Because SDKs operate across entire product lines, a designer can choose a different data acquisition board without rewriting software. For example, if a data acquisition subsystem must be changed from 12 bits to 16 bits, none of the existing software has to be changed. The SDK handles all of the adjustments.

Likewise, if a different kind of board is added, many of the commands may be the same. For example, it is likely that the command used to initialize a data acquisition subsystem will be the same for a frame-grabber board. The designer doesn’t need to learn a completely new set of commands. All of these functions are handled by Dynamic Link Libraries (DLLs).

A Few Words About DLLs

DLLs were invented by Microsoft as an integral part of the Windows operating system. Operating-system functions such as changing menu items or window size are provided by DLLs.

With SDKs, the concept has been extended to provide functions that are required by a subsystem board. The format of DLLs has been standardized by Microsoft. This makes them easier to use because DLLs tend to look alike to the systems designer. A complete system contains DLLs that work together to provide all of the functions required by the system. If a function ever needs to be updated or revised, only one DLL has to be changed-not the entire system.

A Real SDK

It is important to understand exactly what constitutes an SDK. Components vary depending on the vendor. Most suppliers would agree that a good SDK includes a library of software modules (DLLs) to provide the capabilities needed to operate the board. Some DLL calls are generic (RESET, STATUS, CONFIGURE) while others are appropriate to the personality of the specific board (SETCHANNELFILTER, SIMULTANEOUSSTART). The library modules must be configurable to allow the designer to easily select or adjust board operating parameters.

Some vendors supply only device drivers in their kits. These segments of code allow an application to interface to a board subsystem at a very low level and offer limited customization. They do not provide operational functions other than linking user-written software to a subsystem and require additional custom software to do the real work of implementing the functions of a board-level product. For example, Data Translation’s DataAcq SDKT includes fully functional DLLs with driver software contained or even hidden in the DLL (Figure 1, below).

Figure 1.