Bluetooth Stack Implementation in Windows Embedded CE
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/28/2008
The Bluetooth driver is implemented as a streaming device driver that is loaded by Device.exe. The Bluetooth stack is included with Microsoft® Platform Builder. The final application and packaging depends on design template and OEM needs. The stack is modular, so it can be used as a general-purpose software stack, as linked by default, or components of it can be split out and used on their own.
The default link step produces two DLLs:
- Btd.dll
- Btdrt.dll
Btd.dll is the Bluetooth device driver that contains all layers of the stack. It is loaded in device.exe and is used by the AFD as a TDI provider, and also implements the streamer part of the COM emulation port by itself. For more information on the COM emulation port, see Creating a Connection to a Remote Device Using a Virtual COM Port. Sample management functionality is implemented by IOCTLs in the driver's DeviceIoControl function.
Btdrt.dll is a run time thunk DLL that provides a sample management application programming interface (API) to user programs. It accesses the device driver through an IOCTL interface and exposes callable functions.
Every layer is linked directly into a device driver, including HCI (Host Controller Interface) transport, and is not replaceable and extendable once the DLL has been linked, because stack layer APIs are not exported by a standard link step.
However, because a link step is in the user's control, and every layer is provided as a library, any layer can be factored in a separate DLL so it is replaceable in the future. This is mostly useful for creating a device driver with a replaceable HCI transport so transport support can be installed for a particular Bluetooth card.
Another layer that might be useful to expose is the HCI. Extensions can be written to implement SCO, ACL protocols parallel to L2CAP, and controller management commands.
Every layer allows multiple interfaces to sit on top of it, and every upper interface can restrict an incoming connection to a subset of interest. For example, RFCOMM and SDP must only be notified of connections on their own PSM (protocol/service multiplexer); the SCO stack will handle only SCO connections; and a custom software stack might only be interested in connections with just one well-defined Bluetooth device.
See Also
Concepts
Bluetooth Protocol Stack
Bluetooth Stack Architecture