On 23/01/18 21:32, Dennis Lee Bieber wrote:
> On Tue, 23 Jan 2018 20:50:46 +0000, RobH  declaimed the
> following:
>
>> pi@raspberrypi:~ $ gpio -1 write 11 1
>> pi@raspberrypi:~ $ gpio -1 read 11
>> 0
>> pi@raspberrypi:~ $
>
>  At this point I decree that chip GPIO to be totally gone... As a
> working system shows:
>
> pi@raspberrypi:~$ gpio -1 mode 11 out
> pi@raspberrypi:~$ gpio -1 read 11
> 0
> pi@raspberrypi:~$ gpio -1 write 11 1
> pi@raspberrypi:~$ gpio -1 read 11
> 1
> pi@raspberrypi:~$
>
>  Time to check the other GPIO pins for internal functioning. Looking at
> the result of readall, those would be physical/header pins 7, 13, 15, 29,
> 31, 33, 35, 37, 12, 16, 18, 22, 32, 36, 38, 40. Find out if any GPIO are
> working for output. I don't know the internals of the SoC, but could see a
> case where all GPIOs could be killed by one overload, without killing the
> rest of the SoC.
>
>  I don't do BASH shell scripts, or I'd provide one that encapsulates the
> above 5 commands with a parameter for the pin number to speed up the
> testing. In lieu, guess it would be [^] (cursor up) to recall each command
> for editing the pin number (which should be faster than retyping each from
> scratch).
>

I have checked all the pins which you listed for me with

gpio -1 mode pin no. out
gpio -1 read pin no.
gpio -1 write pin no. 0
gpio -1 read pin no.
gpio -1 write pin no. 1
gpio -1 read pin no.

 From the list there are just 6 pins which read 1, and where the
voltages were 3.23 - 3.27 volts

Those pins are
Physical pin no.
13 29 33 37 22 32

Now I am using pin no.32 which gives 3.24V, and the led lights up when
set to (GPIO.HIGH), and goes off when set to (GPIO.LOW).

--- SoupGate-Win32 v1.05