Thanks, I wasn’t aware the TinkerCAD project URLs are available to share yet. I’ve changed the URL to the Thingiverse project I used for the Navio 2 case top, renamed and updated that to include all the models: Emlid Navio Case by CodeChief - Thingiverse
Individual TinkerCAD design URLs (which should work):
Navio 2 Top: Tinkercad | From mind to design in minutes
Navio Plus Top: 3D design Navio Plus Top | Tinkercad
Navio Base: Tinkercad | From mind to design in minutes
The next release 1.0.9 alpha is out on NuGet and GitHub. This completes a major refactor of the framework to support multiple hardware models with automatic detection. Generic interfaces have been added for all devices and a provider/factory pattern now manages the lifetime/singleton of the Navio “board” and devices.
In simple terms it’s easier to use and the same code works on all devices, within limits… Where physical differences occur, like no FRAM or LEDs which are only on or off on Navio 2, additional properties have been added to the interface to allow the consumer code to adjust accordingly. Most importantly when the device and feature exists on the model, it “just works” and behaves the same way as the other models according to the interface contract (compatibility).
After updating the Hardware Test app and all samples and testing switching between Navio+ and Navio 2 it seems like the best way forwards and we should get a future proof/backwards compatible framework this way.
Next step is to gain access to the Navio 2 coprocessor and implement the missing devices (ADC, IMU, GPS). RC input on Navio 2 should work as soon as access to the coprocessor is sorted, but Navio+ RC input has to wait for Microsoft who are currently re-writing their Device Controller management driver to provide buffered and timestamped GPIO events.
Another check-in of major work on the RCIO co-processor. Turns-out the firmware it’s running emulates a PX4IO/Pixhawk co-processor (makes sense, considering APM is the main target). So I have implemented a complete (so far as I am aware) PX4IO protocol and it works! The other hurdle which was solved is access to the second SPI bus from Windows ioT. Basically it works from C++ not .NET.
The Linux RCIO driver was used as a model for the protocol and cross-checked against the official PX4IO firmware repository. Basically it operates on a concept of register/data “pages” which are already split-up into logical groups like setup, configuration, controls, sensors, etc… Here you can see the results in the debugger:
Some work still needs to be done on converting some of the values but they appear to be correct. So I can go ahead and get RC input working with hardware support on the Navio 2. Good news for Navio 1 and Plus owners too is that Microsoft came back again about the GPIO buffering and promised it will be supported in the next SDK release. So lots happening here now.
Along the firmware sides, I’m also implementing the ARM SWD (Serial Wire Debug) protocol so we can fully interact/support/configure/upgrade this co-processor. I’ve started adding an “RCIO Terminal” tool to the soluton for this purpose:
On the language side there was also a “journey”. As it turned out the C++/CX has a successor, C++/WinRT that is highly recommended (and will replace) it as the standard WinRT C++ integration “framework” (it’s actually just header “transformations” which makes it even better, like pure C++ than a heavy/slower wrapper). That’s good but not complete by MS yet so we have a mix of C++/CX for the external interface but can still use the (much) higher performance C++/WinRT code for the internal stuff.
Next steps, finish the RCIO implementation and continue conversion to C++. Right now it only works with Visual Studio 2017 RC and the WDK is not out for that yet so the drivers are not important at this time, they will follow later at lower priority. The C++ framework will perform adequately for the first version.
@CodeChief amazing work on this!
I’m currently getting error “Unable to resolve ‘Microsoft.IoT.Lightning.Providers (>= 1.1.0)’” when trying to add the NuGet package to a new project. Both when I have already added the Lightning NuGet package or when I haven’t and it tries to load it on its own. Any suggestions to resolve?
Thanks! The Lightning Providers are actually removed in the next version and this appears to be a dependency issue when installing the Navio package. Either try to install it separately in the project first then try again, or wait and I will make a new upload probably later today or tomorrow.
The current framework uses C++/WinRT for the low level IO so Lightning is no longer required at least for Navio 2. Actually it appears MS are converging Lightning back into one single provider with new features so it may disappear anyway (or throwing away the “inbox” controller and replacing it with Lightning, depending on which way you look at it).
Did you catch the small release note that the current version only works in VS2017 RC now? I didn’t have time to update all the documentation in all locations yet (just in the code, not on the Emlid site yet). Visual Studio 2017 is due for release on 7th March so maybe they already did something with the Lightning packages.I hope the new/matching WDK and compatible IoT tools should be released at the same time. I’m eagerly awaiting that date to make a big update.
If you didn’t already install that I’d recommend waiting until the RTM release date and making a clean install. Historically beta versions of Visual Studio are known to have issues when upgraded to RTM, sometimes even requiring a complete developer OS reinstall to get it working properly. So best wait for that. By the way they have a nice VM download option which is a good idea to play with: Download a Windows virtual machine - Windows app development | Microsoft Developer
Had picked up VS2017 RC thanks, so using that. As you say, MS packages are a bit of a moving target at the moment so appreciate the effort in keeping up with this.
Will hold off till your next upload, looking forward to getting it going.
Any news on updating the Nuget package? Still having the same issue.
I did try but there were endless problems with Visual Studio 2017 RC and VS 2017 RTM is out tomorrow so it’s best to wait for that. The Release Candidate didn’t compile anymore, very frustrating. The first driver was added a year ago then Microsoft broke the SDK/WDK with ther “external” (will not fix) bug. That was followed by important gaps (showstoppers, Lightning, SPI1 access, etc…) in the framework which they again had solutions to but chose not to release. Since then, we never had a complete set of tools which worked for Unviersal Windows, IoT and driver development.
So I seriously hope the RTM versions tomorrow will finally work like they are supposed to. A bit worrying was the warning at the latest Insider Preview WDK, that installing the driver kit disables Unviersal Windows development. Kindof contradictory. Whatever Microsoft do, they should release a complete set of tools, I have no more time to waste on endless betas and really want to finish the IoT/Navio solution. It’s time to stop the “insider previews” and make something which works. Fingers crossed for tomorrow then!
Thanks for that! Ok, will hold off until RTM is out, as you say, hoping it resolves all these issues.
I’ve completed the 2017 RTM update but the NuGet package script needs some tweaks. It’ll be there shortly…
A new NuGet package 1.0.11-Alpha has been published and the whole solution should work properly with 2017. MS already (just one week after RTM) released a VS217 “update preview” so the VS tools are clearly still “work in progress”. I tested with that and as they specifically state it was intended to solve issues with Universal Windows development, so use that if you get issues with 2017 RTM.
To make all this easier to use some long awaited tasks will be done soon:
The driver/WDK is still dragging it’s heels due to MS tooling issues. Up-vote my comment there if you want some attention on it 
The general advice from MS is to not bother trying to get it working in the same GUI/VS2017 and setup some command line scripts to start/deploy with WinDbg (WDK directly). We already have some PowerShell scripts for the driver deployment so this will be implemented as soon as the next driver development work item continues (after Core SDK and Navio2 hover PoC which can be done without drivers as it has hardware RCIO).
New v1.0.12 checked-in and released to NuGet to support Creators Update preview SDK build 15063 and fix the VSDevCmd location issue using the new standard Microsoft VSWhere tool.
Version 1.0.13 checked-in and released to NuGet to support the release versions of the Visual Studio 2017 Update 1 aligned with the release versions of the Windows 10 Creators Update 1703 SDK and DDK builds 15063 and .NET Core 5.3.3.
All tools are release versions now including the NuGet package. Should make ongoing development easier…
