RC Input (Navio1 Software PPM over GPIO) Hardware Support

[CodeChief]

Add support for the RC Input via GPIO. First version supports CPPM same as Linux but prepare for potential SBUS protocol support.

[CodeChief]

Due to a Microsoft IoT image limitation, specifically with the GPIO #4 pin hard-wired to RC Input on the Navio, we cannot achieve any kind of acceptable performance in "user mode" code. Furthermore, the current UWP API has a lack of support for time critical threads in "user mode". It is necessary to bring forwards the conversion to C++ and device drivers. The next release will include only drivers and provide access via a C++/CX coded Windows Runtime Component. C# code and any other language can then be used as normal for user applications.

[CodeChief]

I also discovered the difference in timings betwen SBus and CPPM. CPPM is relatively slow (~20ms total with >=0.3ms quickest signal change, whereas SBus blasts serial pulses in less than a third of the time, requiring <0.1ms accuracy. So SBus support is also impossible in user mode code on Windows IoT, but should still possible with the driver.

However we should add a feature to support receivers with serial protocols (e.g. FrSky SPort) over the UART connectors or USB to TTL adapters, as it wastes processor time to perform this kind of RC input DSP functionality (which should really be done by hardware).

Image Key: Logic 0 in white is CPPM, and Logic 1 in brown is SBus.

[CodeChief]

Driver proof-of-concept was completed to the point of being able to build and, deploy with VS2015 Update 1 (SDK 1511 and WDK 2015 Update 1), start and communicate with the driver on an IoT system build 10586.

However due to the ongoing bugs in the tools I have decided to switch priority to implementing all other chips in the existing hardware library (C# NuGet package).

The current state of the driver was checked-in a few days ago as part of release 1.0.5. Some screenshots are included below to save time trying to get it working yourself:

Deploying with proper INF package from Visual Studio:

OS driver update boot loader (Windows Phone style):

Driver loaded successfully (also means plug-and-play/ACPI resource assignment working):

Successful access from user mode application:

Next steps:

1. Skip RC Input for a bit, go back and complete all other features in user mode.
2. See if implementation of Navio 2 RC Input hardware is possible in user mode.
3. See if we can get a drone hovering in user mode (with RC input via joystick if still no RC Input solution).
4. Back to writing drivers to provide a real-time robust solution.

[CodeChief]

In the meantime in order to make the software decoding the "best effort" I have switched it over to the "Lightning" provider which is supposed to be 100 times faster. That also updates the I2C devices and adds improvements to later SPI devices when they are added.

However the current GPIO Lightning provider does not support interrupts. I opened a GitHub issue on their "BusProviders" repository and luckily Microsoft responded quickly. They confirmed it is coming soon, perhaps just a few weeks.

See: ms-iot/BusProviders#26

Once that is done I will make a new release with the lightning provider. Perhaps it's fast enough, but it doesn't replace the long term goal to have proper drivers for all the time critical components.

[CodeChief]

MS added support for ValueChanged but didn't add the timestamp. Unfortunately that meant the new higher priority code in the Lightning provider actually slows down our code which still needs to calculate the timestamp, making PWM input even worse!

Updated code will be checked-in soon that supports both modes/providers. Actual results were posted to the end of GitHub issue ms-iot/BusProviders#26 and a new feature request has been made in ms-iot/BusProviders#42.

[CodeChief]

This will take a back-seat now until the rest of the SDK is done.

[CodeChief]

Good news is MS told us in ms-iot/BusProviders#26 that we will should get both the timestamp and a paged buffer of PWM data in an upcoming Insider Preview build. That would be fantastic and (depending on whether the page is in their driver or higher-up) could resolve the need for an RC Input driver at all.

Drivers will still play a role in the long term for realtime/mission critical solutions. But the first complete framework version will be a lot quicker to release and more complete if they really deliver this capability natively in the user mode framework and their standard drivers.

[johnkattenhorn]

This is promising news, we are pushing ahead with planning a driver implementation and are currently studying in the Linux feature sets and code to get familiar. Can't wait to have something for you to review.

[CodeChief]

Microsoft have responded claiming an upcoming Insider Preview SDK will have the missing access to the "Buffered GPIO" features they already released in previous IoT platform updates. This is still low priority because I have successfully implemented RCIO now, we will get fast RC input data from current (Navio2) models. But good news for owners of older Navio models, for backwards compatibility.