Sensors and Windows

Prior to the introduction of WPD, developers wrote a significant amount of code to integrate data from sensors into their Windows applications. But, with the release of WPD, it was possible to create a driver that handled communications between the operating system and the remote device. And, once the driver was written, a developer could write an application with a minimal code footprint—200 lines or less—to retrieve sensor data. For an example, refer to the downloadable whitepaper and code at: https://wpdtempsensor.codeplex.com/. (For an example WPD driver, refer to the WpdBasicHardwareDriver that ships in the Windows Driver Kit.)

For Windows 7, Microsoft introduced the Sensors and Location platform. This platform includes both a driver model for IHVs and an API for application developers. Microsoft recently released a sample driver, sample firmware, and a sample application on the MSDN Code Gallery to demonstrate the use of this new platform. See: https://code.msdn.microsoft.com/motionsensor. This sample, like the WPD sample above, interacts with the Parallax BS2 microcontroller; and, it’s intended as an enhancement (or replacement) of the WPD sample.

So, you may be wondering: “When should I use WPD to support my sensors and when should I use the Sensors and Location Platform?” Good question. The answer is straightforward. If you’re targeting Microsoft Windows XP or Microsoft Windows Vista: Use WPD. If you’re targeting Windows 7, use the new Sensors and Location Platform.

One of the key enhancements of the Sensor Platform is its class extension. The sample sensor driver uses the extension to fire both state-change events and data-update events. So, if the sensor is powered-down or disconnected, the driver calls a single class extension method: PostStateChange. And, each time the sensor sends new data, the driver calls the class extension’s  PostEvent method. The class extension, and these methods, make it very easy to support a “push” model for applications where the app registers to receive event notifications.

Another enhancement is the platform’s “organization” of the sensor universe. The platform identifies specific categories and subcategories of sensors. So, for example, an application can retrieve all of the connected Passive Infrared sensors by invoking GetSensorsByCategory and specifying “BioMetric” as the specific category of interest. (The application developer doesn’t need to look for an identifier supplied by a hardware vendor for a particular passive infrared sensor.)

By the way, if you were to compare the source code for the WpdBasicHardwareDriver and the SensorParallaxSample driver, you’d notice a number of similarities. This is by-design because the WPD and Sensor platform drivers are built on top of the User Mode Driver Framework (WUDF).  The code which configures the serial port, the code that creates the I/O Target, and the code that parses the packets returned by the sensor originated in the WpdBasicHardwareDriver and was ported to the Sensors and Location Platform.

This posting is provided "AS IS" with no warranties and confers no rights.

Comments

• Anonymous
  April 01, 2014
  Cool , But sum these guys use ur info for amo , as I am finding out ! BEWARE THE HACCCCKKKEEEIIIRRSSS .