I2C/GPIO Access from .NET Core 6?

TheZNerd

WinRT support has been removed from .NET Core 5 and up: https://docs.microsoft.com/en-us/dotnet/core/compatibility/interop/5.0/built-in-support-for-winrt-removed

The SDK does not provide support for .NET Core 5 and up at this point - I cannot gain access to any GPIO using the standard namespaces (System.Device.I2c, System.Device.Gpio, etc.). Please advise - this makes the board unusable for any modern development.

TheZNerd

Okay - I have one I2C bus working - apparently the pinout for the board is not correct when using RHProxy. See this document: https://www.annabooks.com/Articles/Articles_IoT10/Windows-10-IoT-UP2-Board-BIOS-RHPROXY-Rev1.6.pdf

Now to test GPIO...

garyw

@TheZNerd
you can try the defult pull down table as attached.

TheZNerd

@garyw - well it was close - it would revert back to low state after closing the pin when high. However, the key seemed to be recompiling the ASL after changing IoRestrictionNone to IoRestrictionNoneAndPreserve. This preserves the pin state when the driver disconnects from the pin.

TheZNerd

Hey @camillus - I see that you seem to be the owner of the current SDK setup files. Can you chime in here please? Has any thought been given to support for the standard libraries/namespaces for .NET Core 5+ (System.Device.Gpio)?

If we can't use the Windows APIs directly, is there any example code for interfacing with GPIO/I2C/etc. from netcore5+? Right now, the SDK includes a WinMD for netcore <5 but this metadata file cannot be used directly in netcore5+ projects.

TheZNerd

One additional thought is that a projection could be created using the C#\WinRT package from Microsoft. See here: https://github.com/microsoft/CsWinRT

Although it would be preferable to just have a driver that allows for access via the standard namespaces (System.Device.GPIO/System.Device.I2c) which just wrap the Windows.Devices.GPIO.dll assembly. My knowledge in this space is extremely limited - but this might serve as a base for support: https://docs.microsoft.com/en-us/windows-hardware/drivers/gpio/gpio-driver-support-overview - although I suspect the driver side of the equation is fully up to AAEON?

garyw

@TheZNerd currently Up Framework has supported .Net Core 3+ not support .Net 5+ yet.
May we know what purpose or reason you have to use .Net 5+ and let us to speed up .Net 5+ support in Up Framework.

Thanks.

TheZNerd

@garyw - support for .NET Core 3.1 ends December 3rd of 2022, no reason to develop a new application on a platform with a shortened support window that has breaking changes between it and the current version. I was previously developing on the DragonBoard 410c, however since Microsoft appears to have dropped support for IoT Core I needed to move to a full windows platform. Additionally .NET Core 5 was released over a year ago (November 2020) - which feels like plenty of time to have tackled this already.

garyw

@TheZNerd Thanks fot the informantion, there are 3 years support in .Net Core lts version like .Net Core 3.1 and .Net Core 3.0 still can using right now just not support from MS.
So most user using UWP app or Desktop app with Up Framework(supported Windows Apis and EAPI) to control GPIO, just few user using .Net Core 3+, so maybe you can considering to using .Net Core 3.1 first and transfer to .Net 5+ when Up Framework is .Net 5+ ready.
We'll plan to support .Net 5+ into Up Framework ASAP, thanks.

TheZNerd

Thanks @garyw - while I appreciate that they may still be used, I don't like writing new software for unsupported frameworks. I'm not sure all the work it would take to migrate this project to .NET Core 3.1, but I'm willing to investigate. Additionally, this change would require me also to rollback to EF Core 3.1 from EF Core 6, which is much less desirable given the amount of work already put into this project.

I need to make a decision on whether to continue with the UP Squared or look into another platform - can a more solid answer to the timeline other than "ASAP" be provided?

TheZNerd

Initial assessment shows this is going to be a massive mess since the project is also written in WinUI 3. I'm not sure it's feasible to rollback to .NET Core 3.1 in a reasonable amount of time.

TheZNerd

@garyw @camillus - WinUI 3 does not support .NET Core 3.1... only supports 5+ - I cannot migrate this project to .NET Core 3.1 or lower at this time. Please advise on updated framework timeline or notify your partner in the service department to allow me to return this device.

TheZNerd

Or is there another method? I can enable the RHProxy on the system by setting the OS to "Windows 10 IOT Core" in BIOS (I'm running Windows 10 Enterprise). I get further with this method as the Windows namespaces can at least see an I2C bus at address 0, but still cannot access the device at the appropriate address (0x77).

TheZNerd

@garyw - when is the expected release of the .NET 5/6 version of the Up Framework API? It is becoming an increasing mess trying to use RHProxy since the documentation on ports on the board is non-existent in this mode.

TheZNerd

Pinging @camillus too - do you want to weigh in here? I'm happy to spend time with an engineer to get this to work. Or if the source code for the drivers can be shared (willing to sign an NDA) I might be able to build a projection from source that is compatible with .NET 5/6 I'd be willing to share back out to your team.

Without this API my project is dead in the water. RHProxy isn't a suitable replacement at the moment with the way the ACPI tables have been built.

garyw

@TheZNerd
if you are fixed HAT 40 pins usage and setting it in BIOS, RHProxy could be another way you can try, let me know your pin usage and I can provide you RHProxy ACPI table for testing.

TheZNerd

@garyw - I need the following at the moment if I'm to use RHProxy:
- 3 GPIO, output, default low (for 3 relays)
- 2 GPIO, input (pull-down), to read a two separate flow meters (hall effect pulse sensors)
- I^2C (two devices, one channel is fine)

I can get I^2C to work with RHProxy (for the most part), the bigger problem is the GPIO. Even when configured as read in the BIOS I cannot read the pins - they're always high. For the outputs, regardless of the BIOS setting they revert to the some default output (high/low) when the pin is closed (see: https://forum.up-community.org/discussion/4864/rhproxy-windows-10-iot-gpio-issues).

I don't particularly care which pins #s are used, but I do need the mapping of board pin # to Windows device (e.g. Pin 34 = GPIO42).

Also if I can be provided the source for the drivers/API (again, happy to sign NDA/IP agreement), I can likely create a C#/WinRT projection that can be used in .NET 5/6 for cases like mine that AAEON/UP are more than welcome to. See this link for more info on projections: https://github.com/microsoft/CsWinRT

garyw

@TheZNerd
I'll provide 3 output,2 input and 1 I2C RHProxy table to you for testing next Monday.
The driver/SDK source code, please send private email to me to discussion, thanks.

TheZNerd

@garyw sent you a private message, I don't have your email

garyw

@TheZNerd
please check up2-test.zip for setting 5 GPIOs and 1 I2C bus, the README has steps for more detail mapping and steps as following.

Testing steps:
1. BIOS setting to initial CPLD direction in BIOS post time, refer BIOS1.jpg,BIOS2.jpg,BIOS3.jpg
2. uninstall UpFramework and run up2-patch.bat as administrator
3. GPIO testing
a. open command prompt and run GpioTestTool.exe -list to show all available pins
b. GpioTestTool.exe 0 to open pin 0 (HAT pin 120
c. pin 2,3,4(HAT 37,38,40) need to setdrivermode output in GpioTestTool
4. I2cTestTool -list to show I2C bus controller

TheZNerd

Thank you @garyw - I will get to testing this tomorrow (2022.03.01) night

TheZNerd

We're getting closer. GPIO0/1 are able to read pulses from the flow meter, and I2C1 bus is working.

However, I still have an issue with state changes on GPIO2/3/4. The pins default low when the device is powered on - this is expected and desired (these pins drive relays that are closed on hot/high) and is the configuration in the BIOS. However, once I open the pin for output (using GpioTestTool), set to low, and then close the GpioTestTool (or close the pin in my code) the pin changes state to High. See the following:

If I let the system sit after this state change, it seems to double-toggle the relays every few minutes too (e.g. GPIO2 goes low and then back to high instantaneously). I can hear the relays click but the pins are still hot.

garyw

@TheZNerd
Which relay you are using? I don't have double-toggle every few minutes in my side.
The pin default status should be the RHProxy driver behavior, first open or pin closed will back to default status (output high), you can considering to add hardware inverter to reverse output because we can't modify MS built-in driver.

TheZNerd

Okay setting the default state to pullDown appears to have done the trick. For whatever reason, the RHProxy driver appears to be resetting to a default state of input after closing the pin, and with PullNone it drives the pin high enough to trigger the relay. Thanks @garyw