(06-10-2016, 03:10 PM)martinayotte Wrote: 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;

(08-25-2016, 07:35 AM)martinayotte Wrote: 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.

(08-25-2016, 08:24 AM)martind1983 Wrote: 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?

(08-25-2016, 11:17 AM)MarkHaysHarris777 Wrote:

(08-25-2016, 08:24 AM)martind1983 Wrote: 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).