ChipCenter Questlink
SEARCH CHIPCENTER
Search Type:
Search for:




Knowledge Centers
Product Reviews
Data Sheets
Guides & Experts
News
International
Ask Us
Circuit Cellar Online
App Notes
NetSeminars
Careers
Resources
FAQ
EE Times Network
Electronics Group Sites

MODULAR INSTRUMENTATION DESIGN


Circuit Cellar Online
THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

MODULAR INSTRUMENTATION DESIGN

Silicon Online Part 1ýDefining the Project
by Bob Perrin

StartThe Problem ý The Solution ý Mechanical Interface ý Man Machine Interface ý Electrical Interface ý API ý In Closing ý Sources and PDF

API

If we provide a solid electrical and mechanical system tailored to the application, the developer will spend the bulk of his time writing code. This means the developer will spend the most amount of time with the API.

Although we havenýt picked a processor yet, we can decide on a software development model. Most developers are comfortable with C. Whatever processor we select will have a C compiler available, so it makes sense to provide a C-based API.

Because we donýt know exactly what I/O set we will have, we canýt fully define the API. But, we can lay some ground rules.

First, the drivers should be given simple names. For example, a function that sets the value of a digital output should probably have a name like DigOut().

Second, drivers should return an error code. It may sound trivial, but it is important the drivers have a uniform interface. This will make remembering how to use the drivers easier for the developer.

The return value will be an int. If the driver completes successfully, the return value will be 0 (zero). If an error occurs, the return value will be non-zero and unique for each error type.

Third, the first parameter passed to each driver will be a number that tells the driver which expansion port it is to talk to. Because the developer can configure several (probably eight) expansion ports with different types of I/O modules, we need to tell the driver which port to talk to.

Fourth, we will build as much functionality into a driver as possible, with the intent of eliminating multiple functions that control the same I/O type. For example, if we have an LED on the controller, we might be tempted to create two functions to control the LED. LedOn() might turn on the LED, while LedOff() might turn off the LED. Instead, we will create one function Led (int value), where value is passed to the function and determines whether the LED will be turned on or off.

Fifth, because sensors are such an important aspect of instrumentation, we will write special functions that each talk to the same basic hardware but return different engineering units. For example, if we have a differential amplifier, we might have a function that knows the developer has a thermocouple hooked up, and returns a value in degrees F or C. The same hardware might support a pressure transducer, and have another function that returns values in mm of Hg or Pascals.

When multiple drivers exist for the same physical I/O module type, the drivers must not interfere with one another. A developer may choose to install two differential amplifiers in the available expansion slots and hook one to a thermocouple, while the second one is attached to a pressure transducer.

PREVIOUSNEXT


Circuit Cellar provides up-to-date information for engineers. Visit www.circuitcellar.com for more information and additional articles.
For subscription information, call (860) 875-2199, subscribe@circuitcellar.com or subscribe online. ýCircuit Cellar, the Magazine for Computer Applications. Posted with permission.

Click here to get your listing up.

Copyright © 2003 ChipCenter-QuestLink
About ChipCenter-Questlink  Contact Us  Privacy Statement   Advertising Information  FAQ