Hardware abstraction – ThingMagic Mercury API v1.23.0 User Manual

Page 17

Advertising
background image

Hardware Abstraction

Introduction to the MercuryAPI

17

Hardware Abstraction

The MercuryAPI is intended to allow cross-product development. The same application
can be used to connect, configure and control any ThingMagic product. However, due to
differences in product features and functionality, 100% compatibility would not be
possible without limiting the capabilities of the API. To allow for application requiring
maximum compatibility and provide full access to all products functionality the
MercuryAPI is conceptually divided into four layers:



Level 1 API

- contains basic reader operations and is hardware and implementation

independent.



Level 2 API

- contains a more complete set of reader operations, including more

complex variations of items in Level 1.



Level 3 API

- contains the set of all operations specific to the different hardware

platforms. Levels 1 and 2 are built using these interfaces. Level 3 is hardware
dependent.



Level 4 API

- provides raw access to the underlying reader protocol for each specific

hardware platform. Level 3 is built on these interfaces. This level is not public and not
supported for user applications.

Note

This is not a technical division, all four layers are available at all times. For
maximum cross-product compatibility the user must be aware of specific
reader capabilities if using classes/interfaces below Level 2.

C A U T I O N !

!

!

Every level implicitly provides support for multiple tag protocols,
including Gen2/ISO18000-6c and ISO18000-6b, even though not all prod-
ucts support them. For maximum cross-product compatibility the user
must be careful when “switching” from high level, protocol independent
tag operations (basic reads and writes) to protocol specific operations,
as defined by the protocol specific subclasses of the TagData class.

Advertising