Issue with GPIO 12 ?
I am trying to control 2 stepper motors in a C++ program thanks to the new-gpio API (thanks again Kit!).
All is fine with GPIOs 0-1-6-7 for the first one, and 8-23-13-14 for the second.
However if I am using GPIOs 8-12-13-14, it does not work : the output of GPIO12 gives nothing (that's the reason why I tried with the next available GPIO on the board, which is GPIO 23.
Would you have any clue ? Is GPIO 12 reserved for some specific purposes (I2C, ...) ?
Thanks in advance, I have designed a PCB routing assuming I would use GPIO12,, and would like to stick on it if possible.
@Frederic-Baumann Really pleased to hear that my new-gpio code is useful and being put to good use
I know of no good reason why you should be having problems with GPIO 12 - I can see nothing in my code that treats GPIO 12 differently from the others. Nor do I know of any other usage of GPIO 12. Could it be a hardware flaw? I will try with my Omega and see if GPIO 12 works as expected.
What I suggest you could do to test GPIO 12 is to use the new-gpio program as follows:
- Run ./new-gpio set-output 12
- Run ./new-gpio set 12 1 and check with a multimeter that GPIO 12 is a logical 1
- Run ./new-gpio set 12 0 and check with a multimeter that GPIO 12 is a logical 0
I just tried all that on my Omega and GPIO 12 does NOT get set to a logical 1 but it did work as expected on GPIO 23
So to try to isolate whether the problem is with my code or the Omega, I tried basically the same using the Omega supplied fast-gpio, so:
- Run fast-gpio set-output 12
- Run fast-gpio set 12 1 and check with a multimeter that GPIO 12 is a logical 1
- Run fast-gpio set 12 0 and check with a multimeter that GPIO 12 is a logical 0
And again GPIO 12 does NOT get set to a logical 1 but again it did work as expected on GPIO 23
- Either you and I have the same hardware flaw on our Omegas Unlikely
- Or there really is something different about GPIO 12 - I have no idea what it could be.
@Boken-Lin or other Omega admins: do you know any reason why GPIO 12 should behave differently from the other GPIO pins?
Looking at the data sheet GPIO12 is also used as a reset, so that might explain why it does not react as you expect.
@mark-titley That's interesting!
Some quick tests indicate that applying a 0 or 1 to GPIO 12 (set as either an input or an output) have no affect on the Omega. And that when GPIO 12 is set as an input, applying a 0 or 1 gives the expected result.
What I find interesting in what you posted is that GPIO 12 is also listed as I2S_MICIN and as UART_CTS and that the other UART_* pins are NOT available as GPIO pins.
Thank you both for testing on your side and reporting these remarks. So I have re-routed my PCB with GPIO23...
@Onion designers: if there is a way to clarify what are the restrictions for GPIO12, I am interested. And same for any other GPIO
little up please as I can see no answer. Are there any restrictions on which GPIOs are actually General Purpose?
I have tested GPIO pins 8 and 12 using the Console and also from the command line using fast-gpio commands.
Let's just say that for GPIO8, the Console's GPIO Tool is messed up! I established a terminal SSH session in PuTTY, and using fast-gpio commands could set GPIO8 as an output or an input; as an output, I could write HIGH or LOW values to the pin and read these values back again, and as an input the fast-gpio read command reports "1" (HIGH) for input voltages above 1.54V and "0" (LOW) for input voltages below 1.48V. Since the I/O runs off of 2.5V (my 2.5V node was at 2.7V), these are pretty reasonable threshold numbers (though they don't agree with the AR9331 spec, but we can talk about that another time). Oddly enough, the Console's GPIO Tool DOES report the correct logic level of the pin after the Sync button is pressed. I think the Console's GPIO Tool code is to blame. I have today submitted a helpdesk ticket for this issue.
GPIO12 is just as bizarre! Regardless of the Console's GPIO Tool settings OR fast-gpio commands, the pin is stuck in the INPUT direction and appears electrically as if it has a weak pull-down resistor to ground (though the resistance is voltage-dependent, so I suspect that a FET might be used instead of an actual resistor). If a voltage above 1.54V is presented to the pin, fast-gpio reads show a logical HIGH state, and below 1.48V show the pin as LOW. The Console's GPIO Tool also reports the correct pin logical state after the Sync pin is clicked. I have also submitted a helpdesk ticket for this issue.
My best guess is that somewhere in the OS these two pins have been hard-coded to only work in the input direction.
When my plate clears up a little bit, I'll look into it in more detail.
@Jeff-Verive Thanks for the update on GPIO pins 8 and 12. Pretty well matches my (less extensive) findings.
Regarding GPIO Pin 8
Implies that it is usable both as an input and an output though I am still puzzled by the existence of the /sys/class/gpio/gpio8 directory and files. Tried deleting these but get an error when doing so. This suggests that it is something in the OS but have no idea what.
Regarding GPIO Pin 12
Implies that it should only ever be used as an INPUT until such time as the Omega people find and provide a resolution
Yes, GPIO12 appears to be coded to be an input. perhaps in the mode settings for the AR9331. For now we can PROBABLY use it as a general-purpose input, but I personally would not do so until we at least have schematics for the Omega.
GPIO8 is a little more confusing to me, mostly because the Atheros AR9331 spec sheet seems to ignore this I/O pin in the section on GPIO registers. This suggests to me that the pin may be reserved for some future functionality. It's probably okay to use GPIO8 for experimenting, but I wouldn't use it in a finished product.
Any definitive update on the GPIO12 issue?
The GPIO8 might be used by the Omega as the power LED, see @Boken-Lin's answer here: https://community.onion.io/topic/360/0-0-5-b251-gpio8-vs-others/3. On the other hand, @Lazar-Demin wrote here: http://community.onion.io/topic/395/gpio-pin-12/4 that GPIO27 is used for controlling the power LED and that GPIO8 "is wacky".
BTW I can set GPIO12 as output:
$ cat /sys/devices/virtual/gpio/gpio12/direction out
But I cannot set it to
$ echo -n 1 > /sys/devices/virtual/gpio/gpio12/value && cat /sys/devices/virtual/gpio/gpio12/value 0
Also, GPIO 8 appears a bit strange but appears to be usable.
A sa consequence I avoid using GPIO 12 and GPIO 8