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 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.
 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.
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.
The text was updated successfully, but these errors were encountered: