Antidote IEEE 11073 stack library
From Wikidb
This is the library that implements the IEEE 11073-20601 stack, and provides ways to adapt the stack to any transport protocol (Bluetooth, USB, TCP/IP etc.)
Contents |
Core Stack
The core stack is written in C, it is transport-agnostic and, to some extent, platform-agnostic. It implements MDER encoding for ASN.1, PHD types, DIM, Agent and Manager.
The API for lower-level componentes (like PHD, DIM) is public, so an application might choose to use only a lower portion of the stack, if desired.
Specializations
The stack accepts device specializations, in the form of compile-time plug-ins. There are some specializations implemented already in stack, and the application may implement more of them.
Transport plug-in interface
The adaptation between core stack (e.g. a Manager) and a given transport protocol is made by a transport plug-in. The transport layer brings the majority of platform dependencies into an application, but the plug-in architecture ensures that stack is insulated from them.
The stack imposes a particular (and very simple) interface for those plug-ins, and the application has a high degree of freedom on how to implement the plug-in.
Threads are allowed, even using one thread per connection (which means that more than one thread may call back the stack at the same time) is OK. The stack uses locks to protect itself (this brings the Pthreads dependence).
Sample transport plug-ins
The library source code contains a number of transport plug-ins. They serve as implementation examples and testing helpers; and their presence makes sure that the library is runnable "out of the box" in certain platforms.
Of particular importance are: the TCP/IP plug-in (which may be used to connect with Continua testing tools) and BlueZ HDP plug-in, which connects to BlueZ HDP implementation.
Health D-Bus Service
The healthd service exports a D-Bus service (com.signove.health). This application serves many objectives:
- Uses the BlueZ (Linux Bluetooth) HDP implementation;
- The API it exports is more simple than IEEE stack API;
- Using D-Bus for the API ensures that all major programming languages have immediate API access;
- Current state of all IEEE devices is centralized on a single service, which in some cases is more convenient, or even mandatory;
- It is a live example of how to implemente an application that uses the IEEE stack.
Dependencies
The core stack has a very light dependence on POSIX (basically on PThreads) which can is easily removed in case you need to port Antidote to a non-POSIX platform. As much as possible of the code depends only on standard library.
Each transport plug-in supplied along with the stack brings its own dependencies. All of them target a Linux platform; some of them depend on GLib, and others employ threads to monitor the transport.
A plug-in that depends on GLib expects that application runs a GLib event loop, so if the application uses another event loop (like Qt, EFL, or implements it from scratch), the plug-in can not be used. A new plug-in, specific for the event loop in question, must be written (of course, the code structure may borrow heavily from the supplied GLib or threaded plug-ins).
Specifically, the BlueZ-HDP plug-in used by healthd service has a fair number of dependencies, including very recent software:
- GLib (any reasonably recent distribution like Ubuntu 10.04 will do)
- BlueZ 4.80 or better (because this version has mature HDP support)
- D-Bus 1.4.0 or better (because HDP API uses file descriptor passing, a novel feature of D-Bus)
- Linux kernel 2.6.36 or better (because of ERTM, a Bluetooth feature that HDP demands)
If compiled with USB plug-in support (as it is, by default), there is the additional dependence on LibUSB 1.0.
The healthd service depends on GLib and D-Bus (dependencies already brought by the BlueZ HDP plug-in).
