Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Windows IoT for Raspbian #114

maruel opened this issue Mar 10, 2017 · 2 comments

Add support for Windows IoT for Raspbian #114

maruel opened this issue Mar 10, 2017 · 2 comments


Copy link

maruel commented Mar 10, 2017


Copy link

@maruel do you have a link to any docs for the implementation on host/winiot? So far, all I have found is info for Windows Universal API's that all require managed (aka .NET CLR) implementations.

Copy link
Member Author

maruel commented Apr 19, 2017

I had filed the issue but hadn't seriously investigated yet. I looked at bit more now.

So "C++" is supported but it is indeed the dotnet dialect, not real C++. I was likely a bit too optimist here. An option is to create a translation DLL that exposes the subset of the needed APIs as a C API, then import this directly without using cgo. This is in the realm of the possible[1] but seems like fighting against the tide a lot with 3 layers of abstractions in the way. I was hoping more for a more direct approach like a Win32 inspired API.

[1] pending not passing afoul Universal App limitations

A good sign is that Win32 API is indeed leaking through the dotnet API, for example GpioChangeReader can raise HRESULT_FROM_WIN32 :) Now if I could get access to the sources of these classes, I could get away from the whole dotnet subsystem and call into the kernel directly.

A good sign is that there is officially support for memory mapped GPIO but the performance page seems to imply it is somewhat slow, that said I need to write a proper gpioperf to have apples-to-apples numbers to compare on Raspbian.

I searched a bit on and but failed to find anything relevant. But then I found and it seems to be what I wanted! So basically open the hardcoded paths, then leverage the code paths guarded with WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP) in, basically it boils down to a standard CreateFile() + DeviceIoControl().

Now we're talking! So the pseudo code would look like:

func GetBaseAddr() []byte {
  h := syscall.CreateFile("\\\\.\\ACPI#INT33FC#1#{109b86ad-f53d-4b76-aa5f-821e2ddf2141}\\0", ...)
  syscall.DeviceIoControl(h, IOCTL_DMAP_MAPMEMORY, ..., &buf, ...)
  return buf.Address

No cgo necessary. Pure memory mapped GPIO access. I think it'd be a good start. DMAP_MAPMEMORY_OUTPUT_BUFFER is defined in DMap.h.

One thing that concerns me if we were able to leverage this is how to transfer this Win32 based executable to the device, I'd need to learn more to streamline this and hopefully integrate into Visual Studio Code or something that makes it user friendly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants