Starting with Windows 10, Windows has had in-box UWP APIs that provide direct access to Gpio, Spi, or I2c busses located on-soc. This gives very easy access to this hardware from a high level API. However, there are many times when a device maker wants to use an off-soc controller to access a bus. It can be as simple as a cheap chip that adds 16 GPIO pins, or as rich as a full MCU (like an Arduino) that not only adds Gpio, SPI, and I2C pins, but also supports PWM and ADC. With the “Bus Provider” model, we give developers the ability to access these off-soc busses using the in-box APIs, using a user-mode provider that bridges the gap.
Someone building a provider implements a set of interfaces into a UWP class library and then any developer who wants to talk to that hardware simply includes the component and tells the in-box APIs about it. If you look at the sample code from the Remote Arduino provider you can see how easy it is to configure the provider and, once set as the default provider for that app, the rest of the code in the client app is identical to the code required to access an on-soc bus.
We currently have a number of providers available on the Bus Providers github repo. In addition to the code for the provider, each provider has a sample VS solution that demonstrates how a client would use that provider.
In addition to the providers that give you access to real hardware, we have built a Simulated Provider that will act as if it was an inifitely capable provider and is designed to let you write and debug your applications without having to first deploy them to a working device. For a richer experience, you can customize it to simulate your actual hardware. For example: updating the I2c provider to return back the result “75” when you send it the command for a temperature reading on a device with the designated slave address.