I have an Energenie RF transmitter add-on board which fits onto the Raspberry Pi header (for more details, see https://energenie4u.co.uk/res/pdfs/ENER314%20UM.pdf). This board allows the Raspberry Pi to control up to 4 Energenie radio controlled mains sockets. I have successfully got it working on a Raspberry Pi B running Raspbian, with a simple Python script to twiddle the 6x GPIO pins it uses. The GPIO pins it uses are:

  • GPIO17 (header pin 11)
  • GPIO27 (header pin 13)
  • GPIO22 (header pin 15)
  • GPIO23 (header pin 16)
  • GPIO24 (header pin 18)
  • GPIO25 (header pin 22)

I've been trying out Windows 10 IoT on Raspberry Pi 2 and I've successfully got it doing a basic flashing LED using GPIO5 (header pin 29), which proves GPIO works, and confirms the Windows GPIO API uses logical GPIO numbering rather than physical pin numbering.

I'm now trying to use the Energenie board with Windows 10 IoT and having an issue using GPIO17 (header pin 11). I use the following code to try and open a pin:

private GpioPin openPinForOutput(GpioController gpioController, int pinNumber)
    if (gpioController == null)
        Debug.WriteLine("GPIO Controller is null");
        return null;

    GpioPin pin = null;
    GpioOpenStatus status = GpioOpenStatus.PinOpened;

    bool success = gpioController.TryOpenPin(pinNumber, GpioSharingMode.Exclusive, out pin, out status);

    Debug.WriteLine("GPIO pin {0} status: {1}", pinNumber, status);

    return pin;

When I call this method for the required GPIO pins I get the following output:

GPIO pin 17 status: PinUnavailable
GPIO pin 22 status: PinOpened
GPIO pin 23 status: PinOpened
GPIO pin 27 status: PinOpened
GPIO pin 24 status: PinOpened
GPIO pin 25 status: PinOpened

I then looked further at GPIO17 (physical pin 11) and found that according to https://ms-iot.github.io/content/en-US/win10/samples/PinMappingsRPi2.htm, Microsoft says physical pin 11 is SPI1 CS0.


Is there any way to reclaim physical pin 11 as GPIO17 in Windows 10 IoT, or are we just stuck with it being permanently configured for SPI1 CS0?

  • The chart isn't Windows specific. GPIO 17 is SPI1 CS0 whether you are using Raspbian or Windows IoT. Even in Raspbian, config modifications, eg to use 1 wire, will prevent some pins from working as general purpose IO. You may be able to change the pin's behaviour by making a config change, as in Raspbian. – Panagiotis Kanavos Sep 17 '15 at 13:05
  • PS. Found that out in Raspbian when I connected a LED to a pin I had previously used for 1-Wire – Panagiotis Kanavos Sep 17 '15 at 13:06
  • Windows, or one of the active tasks, has already opened SPI1. I'm still trying to find out who and why. It's getting in my way, too. – Ron Feb 8 '16 at 15:39
  • When I looked, I found this: developer.microsoft.com/en-us/windows/iot/docs/pinmappingsrpi – David C. Aug 25 '16 at 15:05
  • And your link just redirects me to my link. – David C. Aug 25 '16 at 15:06

It appears that Microsoft have now added Pin Muxing support. As pointed out by David C - my link above has been updated with the following:

"Some GPIO pins can perform multiple functions. By default, pins are configured as GPIO inputs. When you open an alternate function by calling I2cDevice.FromIdAsync() or SpiDevice.FromIdAsync() , the pins required by the function are automatically switched (“muxed”) to the correct function. When the device is closed by calling I2cDevice.Dispose() or SpiDevice.Dispose(), the pins revert back to their default function."

I also note that they now list GPIO17 (pin 11) as defaulting to GPIO now, so it looks like my original issue has now been fixed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.