C GPIO
#1
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?


Attached Files
.tar   gpio.tar (Size: 20 KB / Downloads: 419)
  Reply
#2
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.
  Reply
#3
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.
  Reply
#4
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.)
  Reply
#5
Thank you, it has worked!!
  Reply
#6
(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 Smile

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;
  Reply
#7
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.
  Reply
#8
(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.

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 Smile
  Reply
#9
(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?

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).
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#10
(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 Smile

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).
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  RPi.GPIO python module for Pine A64/A64+ aquilegia 98 129,804 12-15-2022, 08:40 PM
Last Post: Fadazo
  fm transmitter with gpio weasel18 2 4,752 09-10-2019, 04:28 AM
Last Post: desai_amogh
  How to use dts or other setup to declare gpio pin Interrupt (e.g. a button)? dkebler 1 3,546 06-12-2019, 10:37 AM
Last Post: dkebler
Lightbulb Sample GPIO codes highlighting RPi.GPIO-PineA64 and the PI bus MarkHaysHarris777 6 10,955 06-07-2019, 12:37 AM
Last Post: tllim
Star GPIO, SPI and I2C C++ Lib databit 7 11,042 02-04-2019, 05:45 AM
Last Post: Jeff R
Information Howto: Controlling Pine64 GPIO via the filesystem (sysfs) on linux pfeerick 4 11,754 01-24-2019, 03:36 AM
Last Post: Fifth
  GPIO and SPI SamR1 20 31,159 03-15-2018, 10:32 AM
Last Post: jomoengineer
Question GPIO shockr 7 14,582 03-11-2018, 01:52 AM
Last Post: jomoengineer
  Read GPIO problem shworker 14 20,932 08-17-2017, 01:21 PM
Last Post: martinayotte
  GPIO fiq capability joseph 3 6,009 11-10-2016, 06:07 PM
Last Post: joseph

Forum Jump:


Users browsing this thread: 2 Guest(s)