Re-Write Hardware Library as C++ Windows Runtime Component with Drivers

[CodeChief]

After the RC Input proof of concept it was identified that user mode code is too slow for real time devices and all possibilities to use higher priority tasks are blocked by Microsoft design. As originally expected we need a C++ library to more efficiently work with all the bits and bytes, but also run at highest priority and interact with device drivers.

This issue tracks the progress converting the existing PCA9685 (LED & PWM) and RC Input device to C++ and device drivers. After which the remaining issues for other devices (not implemented yet) will track their implementation directly in C++.

[CodeChief]

Delayed due to issues with tools (see RC Input #2).

[johnkattenhorn]

Hey @CodeChief, We have one of our developers available to work on this issue @adamgruchala, he is currently familiarizing himself with the code base and we will PR regularly.

If you would like to give us your input on what you think the priorities should be then please let us know.

[CodeChief]

This particular module is not a good choice. First the proof of concept I am working on for driver development must be done to the point we have no more showstoppers developing, building, deploying, debugging, communicating with and runtime diagnosis of the whole user app to framework to driver call chain. It is extremely likely to change a lot and could get blocked again for months if we hit bugs in the tools for which MS don't publically release the fix for. Then once the method and technologies are there, it cannot be done properly until the user mode framework is complete.

I'll send you an email about the general approach and which modules it would be better to start with.

[adamgruchala]

Our plan was to extend exiting navio driver with interrupt driven gpio reads/writes. That would tremendously reduce latency time. My concern is if in general the userspace application will be fast enough to handle real time operations.

[CodeChief]

You should go and read the history in #12 and the others (there are not many). All of this stuff has already been investigated in depth by me and discussed with Microsoft. They are about to release a new DMA mapped Lightning driver and OS preview which has both event timestamps (the lack of which is the main cause of latency) and a rolling PWM buffer (then we don't need to record individual cycles at all anymore).

Besides that RC Input method is already upgraded to hardware on the Navio 2, so software PWM is only a question for support of the older Navio+ and Navio HATs. That's totally out of scope then for any new product @johnkattenhorn may be building.

I will write the drivers here and convert to lower level C++. I will continue what I already started and indeed write an RC Input/PWM driver even though it is not strictly necessary, just for the purpose of creating a proof of concept driver code base. I don't need any help with that thanks.

[CodeChief]

Brought forward and now top priority because access to the RCIO chip (a proxy to most the useful functionality of the Navio 2 board) is blocked by limitations again programming in C# (or bugs in the tools). The promise of a buffered GPIO driver was not delivered by Microsoft and they are not responding to support questions.

This is the current most active line of development.

[CodeChief]

Indeed successful in C++, the code is now migrating to the "HardwarePlus" project. On the C++ landscape there are also major changes occurring. Basically it seems Microsoft realized the effort and performance coding in C++/CX was not as good as it could have been, because somebody else produced a "Modern C++" header library "projection" which achieves the same COM Interop using standard C++ templates and macros at much faster speeds. So good that Microsoft employ the guy now and he appears to be helping them re-write/replace/renew their WinRT "library" for C++. Joint videos produced with Microsoft state clearly that the benefits are so great that C++/CX is legacy and C++/WinRT will replace it.

After spending lots of time getting C++/WinRT working for actual method code, it was discovered that you still cannot write public external methods with it (useless for writing a component then). In order to save that time and future proof, we end-up with a hybrid solution where as much as possible code is written in C++/WinRT and only the wrapping "adapter" at the start and end of public methods convert to/from C++/CX code at the public external level. This may seem strange but when you consider the benefits it makes sense, especially the more code which is migrated to the C++ hardware component, the more internal fast code can run in C++/WinRT without too many un-necessary translations/casts between that and C++/CX.

C++/WinRT is set as the preferred target language for this solution and later this year we should be able to eradicate C++/CX completely. Next step move all the other components to the C++ project...

[CodeChief]

https://github.com/Microsoft/cppwinrt/issues/93#issuecomment-277464513