A20 GPIO map

[Lurch]

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

[sanzoghenzo]

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 (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, so it's just a matter of time.

[XFer]

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.

[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 guess it's easy to backport only the gpio driver to 3.3... but maybe I'm wrong.

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!)

[XFer]

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.

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!)

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

[XFer]

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

[XFer]

Anyone?

Can't believe nobody attached GPIO trigger buttons to an A20 board running Linux...? 

[olimex]

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

[XFer]

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

[olimex]

sorry, but if you wanted to ask for Interrupt driven GPIOs you had to make this clear not to write:

Is 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

[XFer]

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

[Mouchon]

This

http://www.mjmwired.net/kernel/Documentation/gpio.txt#634

with the wiki information should probably answser your question.

Regards

Philippe.

[XFer]

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

[Mouchon]

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.

[XFer]

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