Upgraded project for Windows SDK 10.0.14393.0

[johnkattenhorn]

We came across this interesting project and wanted to contribute, the instructions were excellent but we had to make a couple of minor tweaks to get it to build in our environment (Visual Studio 2015 Update 3 + Windows 10 Anniversary Edition)

We are very new to drivers and C++ so maybe some of these changes are mistakes on our part.

Some of these staged files seemed to be caused by re-targeting of the platform to the latest build.

Updated TemporaryKey Setup.cmd with new VS_KEY_E22D43B930869187 Updated Setup Local.ps1 $wpdkPath to include revised path Replaced ScrollToVerticalOffset with ChangeView

[CodeChief]

Great. Yes this is a necessary update and the new SDK/DDK was long awaited... I will do a test then merge. I also have outstanding Lightning updates and chipset code to add.

Driver developmemt was blocked by MS broken DDK/tools a while back so Lightning was the only option then. Even that was too long in beta and missed event driven support until recently.

Now the IoT build and DDK have the update, I'm looking forward to getting these drivers back into development. The lightning provider should give some additional time/earlier functionality, may even perform well enough for a higher latency quadcopter PoC. It looks good but I expect for any mission critical/realtime use that drivers are still required.

Hopefully with the new OS build and kits it can move along quickly now ;-)

[johnkattenhorn]

Hey @CodeChief !

We also saw the Lighting Provider as part of the Closed Loop example and agree it took them way too long to get them out to us publicly. We were considering the Lighting Provider the best way forward until we saw this project :-) It maybe that the learning curves ends up being too steep or the blockers you had identified still prevent a reasonable way forward but I thought it's worth a try.

[johnkattenhorn]

@CodeChief - Did you see the email we sent you ? We would like to discuss something commercially sensitive.

[CodeChief]

I had a quick look and there is one general issue with this GitHub commit (at least how it looks at the GitHub.com web site). Files that have not changed appear to be included and those which only changed one setting or one line appear to have changed globally. Do you have different encoding settings of the files or GitHub client configuration? Or do you run some formatting tool which converts tabs to spaces or vice versa?

As 45 changed files are a bit over the top for what is really included, it may be faster and clearer for me to load the project in Visual Studio myself, edit the SDK version and re-apply the other changes. I must do that anyway to complete my outstanding offline changes with the Lightning event handling.

I'll add coding standards documentation soon and some settings files for the common tools if they are not default. I was considering implementing a popular free tool like CodeMaid.

Regarding the setup script, did MS move the path or did you specifically have an issue on a 32bit developer PC? Most should be 64bit which means 32bit WoW when started from a VS command prompt or really 64bit when started directly. If there is a processor specific issue then I'd prefer to use the correct environment variables to build the path. I will test it. Just like to keep the code processor agnostic wherever possible.

Once we get a baseline at the current tools versions and the settings are clear, I hope future commits will go more smoothly ;-) I'll try to sort this all out very soon...

[johnkattenhorn]

Yep, I saw the issue you described with the files with no changes too, even weirder I didn't get the usual "You have mixed cr+lf ....." message either so I don't know what the issue was.

Coding standard document sounds good.

I'd not tried this process before so I can't tell if it's a changed path or not, I simply tried to follow the instruction and when they failed on my machine I went searching for the file and found it in the location I described. I agree we should defintely not introduce anything which is processor specific.

I'm glad this excellent project is not dead. Maybe you could try the upgrade yourself and see if you hit the same issues as us with the latest bits ? We are committed to supporting this project in the immediate future and excited to see where we can take it together.

[CodeChief]

I have completed integration with my Lightning provider changes, actually a complete "HardwareProvider" model which will also attempt to provide basic hardware detection for the different Navio board versions. But during testing there are issues with the Lightning provider I still have to iron-out.

Side-by-side with the "inbox" (non-Lightning) driver the following is observed:

1. The lightning updates fails to sync at all. At least with the software provider it was able to detect the odd frame and the contents made sense (values change in relation to RC input stick movement).
2. The lightning provider locks-up on the second attempt to initialize a different device (I2C or GPIO doesn't matter). The device has to be rebooted before it will work again.
3. The lightning provider still misses the critical timestamp value which I requested from MS and they seemed interested in, but haven't got around to implementing.

With point 1 taking into account, this makes it worse than the current provider. Maybe their own interrupt handlers are now pushing the higher level/lower priority user mode code back so we have less chance of "after the fact" time measurement. If true, that means lightning would be useless without the timestamp property which only MS can provide, or I finish implementing in our own driver (assuming the WDK development tools work again now).

As Navio2 has hardware RC Input, I will just complete my testing and go back to the original plan, to leave RC Input as-is, add support for Navio2, then complete the other device chip support. I hope that point 2 can be resolved with a software workaround (it clearly behaves differently regarding initialization/disposal to the standard provider).

The is only a small chance, that in the final testing I discover a way to get decent timings from the lightning provider. So far it looks like a big failure. PWM value change events without a timestamp are proving to be a waste of time.

This should all be checked-in within a day or two.

[johnkattenhorn]

It's a shame that the Lighting provider is sub-optimal at best, so is the plan to go with a full custom device driver for all the performance critical elements ?

[ivereninov]

add support for Navio2

What is the status of the second SPI driver, has it been implemented by MS yet?

[johnkattenhorn]

@ivereninov - Is that really true :-( I thought this was a limitation of the UpBoard rather than Windows IoT.

Busy doing googling now :-)

[ivereninov]

@johnkattenhorn both is true :) UpBoard does not have the interface physically, while Windows IoT does not seem to support it in software. Linux does support it. Either MS should write the driver or it has to be implemented in user space.

[johnkattenhorn]

That's not so good then :-(

Do you have any links that shares that information ? Just to replay my understanding you access both in User Space (say in C#) but not in Kernel Space (C++ Driver) ?

[ivereninov]

Sorry, I do not understand Windows well, so this is about as much info as I have. @CodeChief is aware of the issue, so maybe he knows what the status of the driver is.

[CodeChief]

The second SPI bus is available at the low level but is blocked by default from user mode access. There is a BIOS hack to get access to it from user mode, but I doubt it will then appear in the standard "providers" as they seem to have blocked access quite deliberately (some constructors/providers are missing, only have "GetDefault" methods).

This article explains how and includes an exact example of SPI1 configuration: https://msdn.microsoft.com/en-us/windows/uwp/devices-sensors/enable-usermode-access

I already created some initial ACPI table source, checked-in under the "Drivers\ACPI" path along with a batch file to help compile it properly. Once compiled you just copy the ACPITABL.DAT to the "C:\Windows\System32\" directory and reboot. It's what you do normally (along with DEVCON) to install a custom driver.

If you get something wrong it will at least hang. Messing around with hardware pin mappings and driver modes could cause damage I suppose, so I wouldn't play around with it too much. The current ASL is configured to map GPIO4 to our "NAVI0001" device driver. I plan to add pins one at a time as each driver is ready. As I'm looking at the whole device initialization issues right now I'll give that 2nd SPI bus a go for you and check-in with the coming update.

To see what it looks like, here is another example of how you can also use the ACPI table to expose a new device to an existing driver which supports the device and bus type: http://www.nxp.com/documents/application_note/AN11767.pdf

The ACPITABL.DAT file seems like a totally hard-coded one-off extension point to me so any manufacturer provided setup routines for RasPi HATs will immediately conflict unless they write their own ACPI aware ASL recompilation into the setup routines. It remains to be seen what MS will provide for OEM HAT driver deployment. Maybe nothing, as embedded projects are typically single purpose devices I suppose we are talking about vendors shipping pre-built images on SD cards with carefully prepared ACPI tables pointing to their chosen driver stack.

What we should do here is (at completion) provide a complete ACPITABL.DAT for each Navio model, which system builders can use to create their own finished devices, or users use indirectly via prepared SD card images, or manually with instructions/setup routine when building their own image.

[johnkattenhorn]

Hey @CodeChief, As i mentioned before we are looking to commit some full time resource to this project and therefore I think I will close this PR and reboot our fork from another GitHub account, we had a lot of issues with the file changes anyway. I'll keep the Applicita one around for reference.

[CodeChief]

All checked-in now. By the way the VS_KEY stuff is unique to each developer machine. So I've updated the TemporaryKey scripts and added documentation to explain that. There are plenty of other changes you will see too. Lots of refactoring and tidy-up. Hardware device access is now much easier, moving towards automatic detection of the hardware model and separation of the chipset code where it makes sense.

The lightning provider does kind of work, but only sometimes better than others. Running the RC Input C# sample (without the whole test GUI) now has more sensible data. As Microsoft promised full tmestamp and PWM buffer support it really doesn't make sense to do anything more here until that is released. So best leave the IoT driver set at the default "inbox" mode if you want to do any demonstrations with this SDK version.

There are still some niggly issues with the build and deployment. The authentication mode "None" is best substituted with "Universal" for a reliable deploy/debug session. And regardless of mode it fails sometimes.

I will also reboot the driver development,. The only reason I stopped is because it was broken a long time ago by the MS image/VS/WDK updates. That is supposed to be fixed now, so I'm eager to test it. The RC Input C++ sample is a stub I am using to test direct driver communication. The RC Input driver will be completed regardless because that is the ideal as a template for the others.

The only thing I didn't manage to complete yet is investigating access to the second SPI bus. I will open another issue for that.

[johnkattenhorn]

@CodeChief, that's really good news; we will re-base our work on the latest bits.