Skip to content
This repository was archived by the owner on Feb 20, 2021. It is now read-only.

Files

Latest commit

author
Terry Fei (Pactera)
push msdn code gallery microsoft
Nov 12, 2019
411c271 · Nov 12, 2019

History

History

Custom driver access sample

README.md

Custom driver access sample

Requires

  • Visual Studio 2013

License

  • MS-LPL

Technologies

  • Windows Runtime

Topics

  • Devices and sensors
  • Windows Store device app

Updated

  • 11/25/2013

Description

This sample shows how to use the Windows.Devices.Custom namespace to access a custom driver from a Windows Store device app.

Important  Starting in Windows 8.1, you can use Windows Runtime APIs to access USB, Human Interface Device (HID), Bluetooth GATT, Bluetooth RFCOMM, Point of Service (POS) and scanning devices from your Windows Store app. Apps written for Windows 8.1 cannot use custom driver access with devices that support these APIs. For more info about these APIs, see

Building and Using the FX2 Samples

The Custom Driver Access (MoFX2) sample application demonstrates how a Windows Store device app can interact with a USB device using a Windows Driver Framework (WDF) driver.

This sample is written for OSRUSB-FX2 Learning Kit device. Full functionality of the sample application requires an actual FX2 device. You can order the device here.

For more info about this device, see the device specification for the OSR USB-FX2 Learning Kit.

This document presumes you want to initially build and run the sample application.

Note  

To run this sample with hardware, you must download an additional sample that provides the driver and metadata for the FX2 device. Depending on whether you would like to use a Kernel-Mode Driver Framework (KMDF) driver or a User-Mode Driver Framework (UMDF) driver, you can download either the kmdf_fx2 sample, or the umdf_fx2 sample.

Installing Your Development Environment

Before you can build and run this sample application, you'll need to complete the following steps:

Related topics

Samples
kmdf_fx2
umdf_fx2
Reference
Device Access API
Windows.Devices.Custom
Concepts
Windows Store device apps
Windows Store device apps for internal devices (including custom driver access)
Device Metadata schema reference

Operating system requirements

Client
Windows 8.1
Server
Windows Server 2012 R2

Build the sample

To deploy the Custom driver access sample solution on a single computer, you must first install the kmdf_fx2 sample or the umdf_fx2 sample, and then use the Device Metadata Authoring Wizard to update and deploy the device metadata that is supplied with that sample.

Note  To use the Device Metadata Authoring Wizard, you must install Visual Studio Professional 2013, Visual Studio Ultimate 2013, or the standalone SDK for Windows 8.1, before completing the steps in this topic. Installing Microsoft Visual Studio Express 2013 for Windows installs a version of the SDK that doesn't include the wizard.

Build and install the Fx2 driver sample

  1. Enable test signing.
    1. Start the Device Metadata Authoring Wizard from %ProgramFiles(x86)%\Windows Kits\8.1\bin\x86, by double-clicking DeviceMetadataWizard.exe
    2. From the Tools menu, select Enable Test Signing.
  2. Follow the build instructions for kmdf_fx2 or umdf_fx2.

Update and deploy device metadata

The device metadata in this step is included in the kmdf_fx2 and umdf_fx2 samples.

  1. Start the Device Metadata Authoring Wizard from %ProgramFiles(x86)%\Windows Kits\8.1\bin\x86, by double-clicking DeviceMetadataWizard.exe.
  2. Click Edit Device Metadata. This will let you edit the existing device metadata package from the kmdf_fx2 and umdf_fx2 samples.
  3. In the Open dialog box, locate the device metadata package. (It has a devicemetadata-ms file extension.)
  4. On the Specify Windows Store device app information page, enter the Windows Store app info for this sample in the Windows Store device app box. Click on Import Windows Store App manifest file to automatically enter the Package name, Publisher name, and Windows Store App ID.
  5. Enter the Privileged application information and check Access custom driver. The app details will be the same Package name and Publisher name that was automatically retrieved in the previous step.

    Note  These build instructions are only for building this sample so it can be tested locally with the Fx2 board. If you are authoring device metadata for your own device rather than the Fx2 board, you must also ensure that the Package name, Publisher name, and App ID are in sync with those that you registered with the Windows Store.

    If the name of the Package name value for the app in the Privileged application section does not match what is imported from the Windows Store app manifest file in step 4, then the app will not be allowed to access the custom kmdf or umdf driver file and you will receive an access denied error when running the sample.

  6. When you're done, click Next until you get to the Finish page.
  7. On the Review the device metadata package page, make sure that all of the settings are correct and select the Copy the device metadata package to the metadata store on the local computer check box. Then click Save.
  8. Restart your computer

Building the solution

  1. Start Microsoft Visual Studio 2013 and select File > Open > Project/Solution.
  2. Go to the directory in which you unzipped the sample. Go to the directory named for the sample, and double-click the Visual Studio 2013 Solution (.sln) file.
  3. Press F7 or use Build > Build Solution to build the sample.

Run the sample

To debug the app and then run it, press F5 or use Debug > Start Debugging. To run the app without debugging, press Ctrl+F5 or use Debug > Start Without Debugging.

Usage Notes

  • The initial launch of the MoFX2 app will show an error message if you select 1) Getting and setting Seven Segment Display, then select Get Seven Segment Display. The error message reads: "The parameter is incorrect. The segment display value is undefined."

    If you select Set Seven Segment Display, it works thereafter. This is because the device initializes the segment display to a non-numeric value. The sample does this to show how to handle error conditions.

  • If you select Show the bar state, the output shown doesn't (literally) match what is displayed on the screen. There are that number of bars lit, it just is that the table displayed by app doesn't visually correspond to bar locations on the device. For example, the screen shows bars 0-4 as lit, there are five lit bars on device; however, the top two and bottom two are not lit. The bar graph display seems odd, but is intentional. It's how the driver and the hardware maps actual the bar line to a number. This is what the functional spec for the hardware says.
  • In the Get the switch state menu option in the sample application the switch number values on the screen don't match what is silk-screened onto the Revision 2 device. The switches on the Revision 2 device start at 1 instead of 0.