I've been expirimenting with GPIO and this is what I've come up with so far. Thought it might be usefull for
sharing.
(http://img59.imageshack.us/img59/776/iwrm.jpg)
Best regards,
Roel P
nice!
you can have look at uboot pio tool we use it to test the board GPIOs at production as Linux still have no GPIO support
hi Ruler,
Thanks very much for providing some light on the GPIO for the A20.
As a newbie to Android and Linux, recently purchased the A20 Android card. Attempting to understand how to access GPIO but have had little success so far. Have tried the "toogle led" example by TsvetanUsunov but there appear to be major differences in file structure between the A20 and A10S, for instance -
PE3 is LED1 = PH2 on A20. Thats should be easy enough to sort out, but the file organisation is different!
A10S : #echo 1 > /sys/class/gpio_sw/PE3/mul_sel does not correspond in any way with
A20 = sys/class/gpio/gpiochip0 to gpiochip229 but excluding gpiochip169 which is for LED1 on the A20 . Does this indicate that you address a specific pin by selecting the gpiochip167 then adding a 2 bit offset? -seems an odd way to do it.
According to linux literature, there should be a way of writing to gpiochipxx with binary values for direction and value, but have not been able to achieve this so far. I would assume that something at a system level needs to be setup first in a config file of some kind but need help to get this underway.
Can anyone provide an example of driving pins on the A20 under andoid?
Many thanks
Hi viseng,
I think you are missing the point with reading the map. The four matrixes actually represent the four 40 pin headers on the board. The bold nr's represent the GPIO nr and the 1 to 40 the pin nr. I uploaded a new picture to clarify. GPIO169 doesn't have to be excluded the signal appears on pin 7 of header GPIO 3.
According to the map:
If you want pin 8 of header GPIO 3 to go high, use GPIO28
If you want pin 9 of header GPIO 3 to go high, use GPIO174
From a terminal do it like this:
Open a terminal(I used a serial port connection to UART0 when I was using Android)
Enter sh
Export the particular GPIO pin. We'll take GPIO169 as an example.
echo 169 > /sys/class/gpio/export
Change the GPIO pin direction to out
echo "out" > /sys/class/gpio/gpio169/direction # we use this GPIO as an output "in" is used to configure as input
Change the value
echo 1 > /sys/class/gpio/gpio169/value # switch it on
(led1 will light and pin 7 of GPIO3 will go high - 3.3volt)
echo 0 > /sys/class/gpio/gpio169/value # and off
Unexport the GPIO pin when done
echo 169 > /sys/class/gpio/unexport
You can read the schematics for function assignments of the pins. All the bold nr's in the map
are usable as output but it's always good to check what functions the 'GP'IO has.
(http://img35.imageshack.us/img35/9127/furu.jpg)
BTW I made a little python GUI program to set the GPIO's, so if anyone is interested let me know.
Good luck
QuoteI made a little python GUI program to set the GPIO's
I'm interested. Please post.
Thank you for the table. It helps a lot.
I will post it soon. Lurch.
Still needs some improvement but getting there. The aim is to create a configuration and save that to
disk so that you can re-upload it to the board. Also the option to set and read IO.
Also made some corrections to the map, turns out 178 and 188 are not usable. Also there's quite some
GPIO that can be exported but isn't yet found on the headers. Once my software fully works it will be simpler
to find out.
Best regards,
Roel
Anyone knows of any news regarding Linux GPIO support for this A20 Olimex board?
Currently published kernel does not support GPIO (no driver).
Had a look on Sunxi but looks like they are not working on the issue...?
Thanks
second revision of A20-Debian is uploaded and linked to Wiki with sysfs GPIO support
Hi many thanks for this second image. Can you provide kernel source and config you used ?
Regards
Thanks Olimex for the new image! :)
I agree with Mouchon, a .config for the kernel source would be great: so we could recompile a custom kernel without having to guess at the zillion options.
Fernando
Thanks ruler for sharing this, and thanks olimex for the debian image.
I'm interest at the linux source and config file, too. Is it from linux-sunxi? because I cannot read any "SUN7I" in the gpio-sunxi driver.
I would like to use (many) gpio pins as buttons, is gpio_keys supported (or will it be) by the gpio driver?
linux-sunxi have no working kernel yet
the Debian image we make is based on Allwinner's kernel which is in A20-SDK you can load it from the wiki link
Thanks Ruler for the excellent work!
A question to everyone who played with GPIO on the A20: are GPIO pins connected to some irq line?
I mean: it would be great if, instead of continuosly checking the status of a given GPIO Input pin (say to read the position of a on/off switch), that pin could trigger an irq that could start a routine.
IRQ-driven instead of polling, that is: like in Arduino. :-)
With Debian image Release2 and kernel 3.3, it looks like we can only use GPIOs via the sysfs; right, or am I missing something?
Thanks!
Fernando
Quote from: XFer on August 11, 2013, 10:03:47 PM
Thanks Ruler for the excellent work!
A question to everyone who played with GPIO on the A20: are GPIO pins connected to some irq line?
that's the reason why I bought this board! I'm not good at kernel driver development, so my board sits in my closet until something magic happens :)
I saw that GPIO driver at linux-sunxi, also used in cubieboard (https://github.com/cubieboard2/linux-sunxi/blob/sunxi-3.4-cb2/drivers/gpio/gpio-sunxi.c)has irq map for a10 and a13. just a matter of adding irq enabled pins in there? If only we could have a good documentation of A20...
It seems to me like an open hardware driven by a black box! :D Hope it will change soon!
No replies?
Nobody thinks that switches, buttons etc. should raise an IRQ to get attention?
Should we stick to polling only?
On a related argument: what is the actual meaning of the [GPIO_xxx] sections of the script.fex?
I mean: on the GPIO Map kindly posted by Ruler, we see that, for example, GPIO26 corresponds to Pin36 of LCD connector (aka GPIO_1 connector).
But in the [gpio_para] section of the script.fex, we have:
gpio_pin_26 = port:PC23<0><default><default><default>
which looks like completely unrelated to the said map.
Moreover, in the script.fex only GPIO1 to GPIO76 are included; despite that, I'm currently using GPIO 167 and 169 to drive LEDs, and they work (at least with kernel 3.3-CB2).
Can anyone shed some light upon the matter? :o
Thanks!
Fernando
Not sure if it helps a lot, but Olimex added some new documents for the A10 / A20 (Schematics, etc.)
two days ago:
https://github.com/OLIMEX/OLINUXINO
Ok, taking a look at A20 manual, chapter 1.19, and olinuxino schematics, I found that there's 32 EINT pins, but they are on the same pin of other functions, so some of them are already used by microsd and usb.
Here's the list:
| EINT | pin name | pin position |
| 0 | PH0 | GPIO-3 pin 5 |
| 1 | SD0-DET# | used by microSD, not on GPIO sockets |
| 2 | PH2 | GPIO-3 pin 7 |
| 3-6 | USB... | used by usb ports, not on GPIO sockets |
| 7 | PH7 | GPIO-3 pin 9 |
| 8: | LCD-PWR | LCD_CONN pin 35 |
| 9-21 | PH9-21 | GPIO-3 odd pins from 11 to 35 |
| 22-23 | PI10-11 | GPIO-2 17 e 19 |
| 24-25 | UART6-tx/rx | UEXT1 3 e 4 |
| 26-27 | PI14-15 | GPIO-2 30 e 32 |
| 28-31 | SPI1-... | UEXT-2 10,9,8,7 |
on the driver side, in the gpio-sunxi driver (https://github.com/linux-sunxi/linux-sunxi/blob/stage/sunxi-3.4/drivers/gpio/gpio-sunxi.c) (line 321-341) there's the irq map for A10, identical to A20, so it's almost ready for gpio interrupts! A patch is already been sent to linux-sunxi google group (https://groups.google.com/forum/?hl=it#!topic/linux-sunxi/_1WVqev6cQY), so it's just a matter of time.
Quote from: Lurch on August 25, 2013, 09:18:45 PM
Olimex added some new documents for the A10 / A20 (Schematics, etc.)
Already seen them, unfortunately schematics don't help with GPIO maps and irqs at kernel level. :(
@sanzoghenzo:
Those gpio-related patches are for kernel 3.4, which has a lot of issues on its own (much worse than 3.3 for my needs: issues with USB and audio, for example).
I have to say, software and documentation support for A20 is quite slow.
Looks like a board starts having decent support when it's already surpassed by a new board.
Quote from: XFer on August 26, 2013, 12:05:23 AM
Those gpio-related patches are for kernel 3.4, which has a lot of issues on its own (much worse than 3.3 for my needs: issues with USB and audio, for example).
I guess it's easy to backport only the gpio driver to 3.3... but maybe I'm wrong.
Quote from: XFer on August 26, 2013, 12:05:23 AM
I have to say, software and documentation support for A20 is quite slow.
Looks like a board starts having decent support when it's already surpassed by a new board.
Sad but true :(
I imagined an Arduino like approach, with APIs to unlock the full potential of the board (and SoC).
Now I realize we are the ones supposed to make this happen (but I don't have the resources and knowledge to do it!)
Quote from: sanzoghenzo on August 26, 2013, 12:38:31 PM
I guess it's easy to backport only the gpio driver to 3.3... but maybe I'm wrong.
Unfortunately, you are: 3.3 and 3.4 are too much different in GPIO and USB stuff (for example), to easily backport 3.4 patches to 3.3. :(
QuoteI imagined an Arduino like approach, with APIs to unlock the full potential of the board (and SoC).
Now I realize we are the ones supposed to make this happen (but I don't have the resources and knowledge to do it!)
My thoughts exactly. I, too, come from the Arduino mindset.
Among Linux boards, I like what Raspberry PI is doing: while not really open and not 100% documented, they did a great thing concentrating on just 1 model for a long period of time.
This facilitated building a shared knowledge, writing docs, fixing issues, building drivers and optimized software.
Having too many models, one after another, is, well, confusing; in my opinion of course.
Without good support (as in: docs and system software), is difficult to follow a coherent developement cycle (new idea, design, prototype on developement board, produce on SOM board).
Fernando
Hello,
45 days later, we have a much newer kernel.
Is there a way to tell if a switch connected to a GPIO pin changed its state?
Let's say I have a hardware button and I want to launch a shell script whenever I trigger it: how can I do that?
Thanks
Anyone?
Can't believe nobody attached GPIO trigger buttons to an A20 board running Linux...? :'(
reading the wiki would spare you much time :)
https://www.olimex.com/wiki/A20-OLinuXino-MICRO#GPIO_under_Linux
you make the port input with
#echo in > /sys/class/gpio/gpioXXX/direction
then
check the status with
#cat /sys/class/gpio/gpioXXXX/value
it will return 1 or 0
Readying the MESSAGE in its entirety would have spared you a worthless reply.
I need INTERRUPT-DRIVEN reading, I have TRIGGERS not on/off switches.
Fer
sorry, but if you wanted to ask for Interrupt driven GPIOs you had to make this clear not to write:
QuoteIs there a way to tell if a switch connected to a GPIO pin changed its state?
and responding rude will just guarantee that I will not bother to read your posts in future
My compliments, very professional.
I was rude because you were being ironic and provocative, without having even bothered to read the full message.
I, of course, already have read everything the wiki had to offer about GPIO, otherwise would not have posted a cry for help here on the forum.
Fernando
This
http://www.mjmwired.net/kernel/Documentation/gpio.txt#634
with the wiki information should probably answser your question.
Regards
Philippe.
Mouchon, thanks for the suggestion, anyway I know that generic Linux kernel document, too.
Problem is, sunxi kernels, even the latest 3.4, are not 100% aligned with the official Linux kernel, so they differ in some ways.
For example, I can't find the special sysfs files for interrupt handling (GPIOs I/O files are there, "edge" special interrupt-related files are not).
I was hoping someone already managed to implement a function triggered by a IRQ associated with one of the GPIO pins.
Let's say you have a trigger push button connected to a pin on one of the A20 GPIO connectors and want to do something when the button is (briefly) pushed.
You can't simply continuously read off GPIO like it was kindly suggested by "olimex", because of course if the push duration is only a fraction of second, you should always keep reading the port in a tight loop, which is very inefficient (and you may miss the push anyway).
Since some GPIO pins are connected to IRQ lines, the hardware is capable of triggering an interrupt when the button is pushed.
So in theory (like on Arduino and RaspPI), one could use a callback function to do stuff when the interrupt is detected.
I was hoping someone already did something like that, specifically on Olinuxino A20 (not generically on Linux etc.), to get some suggestions on a proper implementation in C.
Somewhere else on the forum it was suggested to look for a GPIO C library bundled with a Python utility.
Too bad, that the library does NOT handle interrupts, so it's useless in this case.
Fernando
Xfer,
in sys/class/gpio only exported gpio that can handle interrupt have edge file
so use the bash loop proposed in the wiki and look which one have edge
echo 48 > /sys/class/gpio/export will create the pio48_ph7 in which edge are in .
This work with kernel linux-sunxi i compiled from stage/sunxi-3.4
So if you do select or poll on this you will receive interrupt event.
i agree that it will be more simpler to have ioctl on it to give callback function. But this is not the case.
Hi Philippe,
my 3.4 kernel (main branch, not stage) does not create edge files from exported GPIO interfaces.
I'll have to try the stage branch. Hoping it does not break other stuff. :-(
Thanks for the head up!
Fernando
Quote from: Mouchon on October 17, 2013, 09:34:37 AMi agree that it will be more simpler to have ioctl on it to give callback function. But this is not the case.
I don't think there is really any good way to do this on Linux/Unix based systems.
At least with a poll() or select() the caller is in control of when the service handler is run. With a callbeck there is the added complication of contact bounce on mechanical switches, which could result in the callback function being called several times (once for each time the contacts open and close) over a few milliseconds. That would mean having to write debounce code into your function, which is added complexity.
What we really need is a high-level library that removes the need to have to program down at the pin level. I guess it'll come, given time.
hi all, back to olinuxino since I have some spare time... Is there any news on the irq-gpio stuff? do you find some good workaround for reading key presses?
I think I'll have to move to raspberry pi to make my arcade cabinet controller/system... too bad, the A20 hardware is much better, but without software/drivers to drive it is pretty useless... :S
I'm working on A10(LIME), but it's more or less the same.
First, you may use only gpio with irq support - look at gpio description.
# ls /sys/class/gpio/gpio65_pi10/
active_low device direction edge power subsystem uevent value
edge option tell you - gpio is irq ready
# echo falling > /sys/class/gpio/gpio65_pi10/edge
echo put gpio in irq mod
# cat /proc/interrupts
CPU0
0: 0 sw_vic axp_mfd
1: 331 sw_vic serial
.......
117: 0 gpio-sunxi gpiolib
Err: 0
117 is your gpio interup number
For more information look at:
https://lkml.org/lkml/2012/4/10/118
and: https://developer.ridgerun.com/wiki/index.php/Gpio-int-test.c