C GPIO

[igna09]

Hi guys, i've found some materials about sunxi c gpio controlling at these link:
http://docs.cubieboard.org/tutorials/com...on_lubuntu
http://linux-sunxi.org/GPIO#C.2FC.2B.2B_program.
When i try to run it return  me segmentation fault. Is a problem of my pine or isn't good for all pine64?

[martinayotte]

I've took a quick look and it seems to fail in the mmap initialization providing wrong address used in setcfg().
In the mean time I will figured out, maybe you should look at https://github.com/swkim01/RPi.GPIO-PineA64
Although it is for python, the python is only a wrapper around their own c_gpio, so it can be used in plain C too.

[igna09]

Thank you, yes i arleady use the python code but i was searching for a c code because i was thinking that it was faster.

[martinayotte]

Ok ! I found the issue and got it working : like many other libs, a 32bits pointer used in 64bits environment !

You need to change the "unsigned int SUNXI_PIO_BASE" for "unsigned long SUNXI_PIO_BASE" in both gpio_lib.c and gpio_lib.h

(BTW, about speed of python vs C/C++, that all depends of you apps. Of course, if you wish to toggle gpio at maximum speed, C/C++ could do better.)

[igna09]

Thank you, it has worked!!

[martind1983]

Ok ! I found the issue and got it working : like many other libs, a 32bits pointer used in 64bits environment !

You need to change the "unsigned int SUNXI_PIO_BASE" for "unsigned long SUNXI_PIO_BASE" in both gpio_lib.c and gpio_lib.h

(BTW, about speed of python vs C/C++, that all depends of you apps. Of course, if you wish to toggle gpio at maximum speed, C/C++ could do better.)

Hello Mr. Martin

Can I ask you how this memory mapping worked for you with base address starting at 0x01c20800 for gpio. Because when I use mmap I get EINVAL "invalid argument" because this address is not aligned to page size multiplication. What address or how could I directly access GPIO registers?

I do it like this (see comments in code below) but LED connected to PB1 does not light. I even tested it over sys/class/ drivers and that works. LED is connected to physical pin 10 according to this pin layout. I just want to test board and play around.

http://joey.hazlett.us/pine64/pine64_pins.html


Thank you very much.               Martin

MY CODE:
    // map memory image to virtual memory for direct writing in the peripherals
    // BASE_ADDR is 0x01C20000

    p_mem = mmap(NULL, page_size * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, BASE_ADDR);
    if (p_mem == (void *) -1) {
        perror("mmap");
        exit(EXIT_FAILURE);
    }

    // convert void * to unsigned long *

    gpio = (volatile unsigned long *) p_mem;

    /*
     * add offset 0x800 to maped base address to get to PIO registers
     * plus add offset to PB_CFG0_REG 0x24 to PB1 as output, 0x8 should set PB1 to output mode
     * for output to log 1, the same I set offset 0x800, plus I add offset to PB_DATA_REG 0x34
     * to set 1 for PB1
     */

    *(gpio + GPIO_REG_OFFSET + 0x24) = 0x10;
    *(gpio + GPIO_REG_OFFSET + 0x34) = 0x02;

[martinayotte]

The PB0/PB1 are used by the UART by default.
If you wish to use them as plain GPIOs, you first need to disable the UART is the DTS.

[martind1983]

The PB0/PB1 are used by the UART by default.
If you wish to use them as plain GPIOs, you first need to disable the UART is the DTS.

Thank you very much man.

One more question. All the pins led out on the board and which are also dedicated to some peripherals I have to first turn off special functionality before using them as normal GPIO?

Thanks.                 Martin

[MarkHaysHarris777]

One more question. All the pins led out on the board and which are also dedicated to some peripherals I have to first turn off special functionality before using them as normal GPIO?

No, not necessarily.

... as long as the pins (channels) are not actually being used 'now' you can use them for what-ever you want. But, that's a big if.  If a driver is running that uses the channel, you will need to stop and unload the driver... but, you don't necessarily have to edit the dtb|dts in order to do this.

That said, it is best to use GPIO pins that are 'free' first.  On the diagram , the green and then maybe the blue. The main exception right now is the pin(7) GPIO04 which is s-pwm and used for the LCD backlight... because it is on a pwm channel even though you can turn it on and off (if you have the correct base address, or use sysfs) it still doesn't work right, because it is 'very' dim ... and, it has a pwm signal on it.  In this case you must not only edit the dtb|dts, but also unassociate the pin, and you need to stop the driver and unload it (a lot of work, just use another GPIO pin).

[martind1983]

Hi Mark.

First off, thank you for comprehensive help.

Thus, as I got your point. I do not have to modify device tree because of pins connected to some peripheral, just to stop and unload driver should be enough. However, this is not completely through for every peripheral. Thus, for some of them I also have to modify device tree and un-connect so pins (I want to use) and which are also dedicated to peripherals.

For example: I cannot find that UART peripheral driver to which PB0, PB1 would be loaded in the kernel. Does it mean, that I also have to modify dts/dtb to un-connect these two pins from UART2 in device tree?

Is such a rule valid for all GPIOs connected to peripheral which information about is enumerated in DTS?

Thank you.                                     Martin

One more question. All the pins led out on the board and which are also dedicated to some peripherals I have to first turn off special functionality before using them as normal GPIO?

No, not necessarily.

... as long as the pins (channels) are not actually being used 'now' you can use them for what-ever you want. But, that's a big if.  If a driver is running that uses the channel, you will need to stop and unload the driver... but, you don't necessarily have to edit the dtb|dts in order to do this.

That said, it is best to use GPIO pins that are 'free' first.  On the diagram , the green and then maybe the blue. The main exception right now is the pin(7) GPIO04 which is s-pwm and used for the LCD backlight... because it is on a pwm channel even though you can turn it on and off (if you have the correct base address, or use sysfs) it still doesn't work right, because it is 'very' dim ... and, it has a pwm signal on it.  In this case you must not only edit the dtb|dts, but also unassociate the pin, and you need to stop the driver and unload it (a lot of work, just use another GPIO pin).