Since .NET 5 the Assembly.Location API returns an empty string when the app is deployed as single file executable.
https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file

This prevents the library from using with a single file deployment.

Error
The basePath variable will be empty.

Exception

System.ArgumentNullException: Value cannot be null. (Parameter 'path1')
   at System.IO.Path.Combine(String path1, String path2)
   at Unosquare.WiringPi.Resources.EmbeddedResources.ExtractAll()
   at Unosquare.WiringPi.BootstrapWiringPi.Bootstrap()
   at Unosquare.RaspberryIO.Pi.Init[T]()
   at HorseFeeder.Raspberry.InitializeService.InitializeRaspberryPi()

Possible solution
I'm not 100% sure but maybe it's possible to use AppContext.BaseDirectory to get the basePath.
https://docs.microsoft.com/en-us/dotnet/api/system.appcontext.basedirectory?view=net-5.0#System_AppContext_BaseDirectory

Describe the bug
GPIO BCM 14 and 15 only have the UARTTXD / UARTRXD capabilities, even when the UART is disabled with enable_uart=0 in config.txt. This prevents use as regular GPIO pins.

To Reproduce

1. Disable the UART on pins BCM14/15 in config.txt with enable_uart=0.
2. Attempt to set Pin Mode to Input or Output using Pi.GPIO[14].PinMode = GpioPinDriveMode.Input
3. Receive System.NotSupportedException: Pin 14 'BCM 14 (TXD)' does not support mode 'Input'. Pin capabilities are limited to: UARTTXD
4. Using the gpio(1) command-line tool on the Pi, run gpio -g mode 14 in to set the pin mode to input
5. Verify signals can be read using gpio readall

Expected behavior
When the UART is not using pins BCM14/15, it should be possible to use these as general purpose I/O pins.

I'm very happy to submit a PR to just add the GP capability to those pins, but I wasn't sure if you wanted to do some runtime detection of whether the UART is enabled before allowing it (i.e. only report that capability if the UART is not enabled), or whether it's acceptable to always report the capability, because the underlying hardware possesses it.

Environment:

• OS: Raspbian GNU/Linux 10 (buster)
• .NET 5.0
• Unosquare.WiringPi 0.5.1
• Unosquare.Raspberry.IO 0.27.1
• Raspberry Pi 3

Please bear with me.

I'm trying to use the II2CDevice.Read(int length) method to bring back a six-byte array off the bus. The behavior, though, is that it is bringing back six copies of the FIRST byte of the bus. I've tried this many times, many ways, and all I get back is six of the same byte. Note also, this is a purchased I2C device (a Thunderborg) so I am unable to change its behavior. I've seen in a similar bug elsewhere that the solution was to change a connected Arduino's code to work in a specific way. I've also seen that I should be able to access the underlying WiringPi.Read(int fd, int length) type function, but that is beyond my ken at the moment.

To Reproduce
Steps to reproduce the behavior:

for (int kb = 0; kb < splash.Length; kb++)
{
     log.WriteLog("Found: " + splash[kb].ToString("X2");
}

Expected behavior
This SHOULD produce 0x99/0x15/0x00/0x00/0x00/0x00

Screenshots
It produces:

16/03/2021 22:09:06: Found: 99
16/03/2021 22:09:06: Found: 99
16/03/2021 22:09:06: Found: 99
16/03/2021 22:09:06: Found: 99
16/03/2021 22:09:06: Found: 99

Desktop (please complete the following information):

• Raspberry Pi 3
• .NET IoT 3.1

Additional context
Any help would be appreciated.

Hi guys!
Been playing with hardware PWM on RPi 3B and encountered this issue:
When switching GpioPin.PinMode to GpioPinDriveMode.PwmOutput, the underlying WiringPi library immediately starts the clock. That's probably the right thing to do, as long as one gets a chance to set the desired duty cycle first. That could be done by calling pwmWrite(pin, val) which doesn't care if a pin is not yet in PWM mode. However, the wrapping setter in GpioPin.PwmRegister throws InvalidOperationException because the pin hasn't been switched to PwmOutput. But if we switch the pin to PwmOutput, the clock is started and the default range and divisor kick in immediately, producing an "arbitrary" burst signal for at least the 100 microsecond delay that is hard-coded in WiringPi, before any code gets a chance to adjust those parameters and set register value to the desired duty cycle. The way it manifests itself with an LED is a short burst of light until the proper duty cycle gets set.
Having the mode check in the PwmRegister property setter commented out and setting a value prior to switching pin mode, I was finally able to start PWM with any desired duty cycle (e.g. a flat-line zero).
I believe this is important if one wants to get a predictable PWM output right off the bat when starting a motor at a low speed or slowly lighting up an LED without getting an uncontrolled initial "burst".
Let me know what you think. - Advance thanks!

I am porting some code from python to c#.

I have a simple setup using a RP3 with a SenseHat and an external Button (wired between pin 16 and GND ).

In python I used the following code to achive a bounce free function call after a button press:

import RPi.GPIO as GPIO

GPIO.setmode(GPIO.BCM)
GPIO.setup(16,GPIO.IN,pull_up_down=GPIO.PUD_UP)

def nextTick(*args)
  # do my stuff here

GPIO.add_event_detect(16,GPIO.FALLING,callback=nextTick,bouncetime=200)

with your libary i tried:

Pi.Init<BootstrapWiringPi>();
var pin = Pi.Gpio[16];
pin.PinMode = GpioPinDriveMode.Input;
pin.InputPullMode = GpioPinResistorPullMode.PullUp;
pin.RegisterInterruptCallback(EdgeDetection.FallingEdge, ButtonCallback);

this works for detecting the button press, but since the button is quiet cheap I get up to 10 function calls each time i press the button.

Would it be possible / or is it allready possible to add a bouncetime to RegisterInterruptCallback() to drop incomming interrupts in a given time window to remove bounce from the button?

I tried to use your example:
// All 3 methods below are exactly equivalent
var blinkingPin = Pi.Gpio[17];
blinkingPin = Pi.Gpio[BcmPin.Gpio17];
blinkingPin = Pi.Gpio.Pin17;
There is only Unosquare.WiringPi namespace, which does not have "Pi" class

It is necessary to use a new version of WiringPi 2.52 in order to get the library working in Raspbian Buster and the Raspberry Pi 4B.

More info

IGpioPin does not give access to all PWM functions.

In Workbench, the Servo demo should take an IGpioPin in the constructor, not a GpioPin.

Alternatively explain in docs how to get a GpioPin instance from
Pi.Gpio[bcmPinNumber]