Yet more on GPIO interrupts



  • With reference to these two earlier topics:

    Using build of relevant packages using information covered in:

    I have built (and I believe successfully installed) .ipk packages for:

    However, while I believe I have got further than before, I am still having some problems.
    Specifically running gpio-test 0 (which should detect a change on GPIO pin 0) does not appear to work (even though I can independently verity that the input state on GPIO pin 0 does change appropriately). I get the output:

    • Waiting GPIO 0 signals...

    and no further output.

    However, I do note the following possible issues in relation to gpio-irq:

    1. There is the following comment in the README.md file for gpio-irq:
    2. The gpio-irq package needs to be installed using opkg -force-depends ... since it reports that a later version of the kernel is required - this may be related to the previous point
      Does anyone have any info on this too?

    Thanks in advance for any responses :-)



  • Additional relevant comments on this.

    The code in gpio-test has the following:

    • fd=open("/sys/kernel/debug/gpio-irq", O_WRONLY);
      if(fd < 0)
      {
      perror("open");
      return false;
      }

      sprintf(buf, "+ %d %i", gpio, getpid());

      if(write(fd, buf, strlen(buf) + 1) < 0)
      {
      perror("write");
      close(fd);
      return false;
      }

    This code appears to run OK with no errors and should have written to the file /sys/kernel/debug/gpio-irq - this file exists and appears to have the correct access rights, yet after running the code, this file is empty.

    This file should (once gpio-test is running) have the contents:

    • + n p where n is the GPIO pin number and p is the process id

    On termination of gpio-test it should have contents:

    • - n p where n is the GPIO pin number and p is the process id

    Yet the file appears to never change :-(


  • administrators

    Hi @Kit-Bishop, I believe i've sent you the source to that patch a while ago in a separate post. Currently the patch hasn't been implemented in the Omega firmware. Here's the link again for the patch for kernel version 3.18: https://github.com/GBert/openwrt-misc/tree/master/gpio-test/src/patches-3.18.



  • @Boken-Lin Thanks - I must have overlooked it. I will try installing the patch and rebuilding and see what happens.
    Apologies for wasting your time :-(



  • YAY!! I Have got GPIO interrupts working from user mode C/C++ code. :-)

    For the record, I did the following:

    1. Applied this patch to the OpenWrt sources (as in https://wiki.onion.io/Tutorials/Cross-Compile)
    2. Built a release using these sources including gpio-irq (i.e. kmod-gpio-irq) and gpio-test packages
    3. Copied the file openwrt-ar71xx-generic-onion-omega-squashfs-factory.bin from the
    4. Installed the built release on my Omega using sysupgrade openwrt-ar71xx-generic-onion-omega-squashfs-factory.bin
    5. Ensured gpio-irq (i.e. kmod-gpio-irq) and gpio-test were installed from the .ipk files generated above
    6. Ran gpio-test N & (where N is the GPIO pin number) and observed that interrupts were detected and reported when the state of pin N was changed
    7. Wrote a small amount of C code that used similar techniques to gpio-test and checked that it too correctly intercepted the interrupts.

    The only relevant observation I can make is that because of this line:

    • int err = request_irq(irq_number, gpio_edge_interrupt, IRQ_TYPE_EDGE_BOTH, "gpio_irq_handler", data);

    in gpio-irq.c the interrupt is triggered on both the rising and falling edge. The specific case can be detected from the state of the pin when the interrupt code is called. I may consider a patch that allows setting for rising or falling edges specifically, but it is not a big deal.

    As a consequence, I would HIGHLY RECOMMEND to the Omega people that, in the next (or relatively soon) release of the Omega code, the patch (https://github.com/GBert/openwrt-misc/blob/master/gpio-test/src/patches-3.18/739-MIPS-ath79-add-gpio-irq-support.patch) be applied and that package kmod-gpio-irq be included.
    Then, GPIO interrupts will be standardly available in the Omega without additional work.


  • administrators

    Hi @Kit-Bishop, were you able to get the edge file to work in the sysfs interface? We will definitely add the patch into our buildroot so that the next update will have the irq support built-in.

    Thanks!



  • @Boken-Lin No, I was never able to figure out how the edge file could be created and used via the sysfs interface. But since with the kernel patch and usage of kmod-gpio-irq I can now successfully deal with GPIO interrupts in C/C++ based on the code in gpio-test I am happy with what I can now achieve.

    A relevant comment is that in playing with code based on gpio-test I have found:

    • There is only a single irq handler that can be installed using the existing code

    • BUT amongst the information passed to the irq handler is a structure that in one of its fields gives both the pin number for which the handler is called and the state of the pin - with this, it will be easy to write some code that:

      • Calls on to an additional handler specific for an individual pin
      • Can distinguish between rising and falling changes in the pin

      I will be updating my new-gpio code to incorporate GPIO pin interrupt handling capabilities based on this.

    Some interesting information about how the kmod-gpio-irq code works is:

    • It works by detecting writes (in user mode code) information about the pin number and the process id to /sys/kernel/debug/gpio-irq to enable and disable interrupt handling for the pin
    • When interrupt handling for a pin is added by writting to /sys/kernel/debug/gpio-irq the following line is created in /sys/kernel/debug/gpio (e.g.for pin 6):
      • gpio-6 (GPIO IRQ handler ) in lo
    • This line is removed when the interrupt handler for the pin is removed

    As an aside, the default contents of /sys/kernel/debug/gpio are :

    • gpio-8 (USB power ) out hi
      gpio-11 (reset ) in lo
      gpio-27 (onion:amber:system ) out lo

    Of these:
    a. I don't understand why gpio-8 is there (????)
    b. gpio-11 makes sense since pin 11 is the reset pin
    c. gpio-27 makes some sense since I understand that pin 27 is the Omega LED



  • @Boken-Lin A few days ago, you said: We will definitely add the patch into our buildroot so that the next update will have the irq support built-in.

    This is NOT meant to be a complaint or hurry up, but do you have any rough idea when the updated with GPIO irq support as per the patch will be available?

    The reason I ask is that I have now got some significant C/C++ code (as an extension to the new-gpio code I posted some time ago) that from my testing appears to work well in handling GPIO interrupts.

    This includes a test program that in a very simple manner can be used to set a background program running that, on an interrupt (e.g. a button press), will run any shell command specified at the time the program was started. Thus allowing running of any command to be associated with a button push - multiple such instances can be set up - one for each GPIO pin if so desired.

    However, this code is dependent upon:

    1. A kernel version with the above patch
    2. Installation of the kmod-gpio-irq package

    I would like to post this code since I believe it would be of general use, but there is no point in doing so until the update is generally available.


  • administrators

    @Kit-Bishop We will be putting out a new firmware today. :)



  • @Boken-Lin Great :-) Thanks. Didn't mean to give you a hard time over this.


  • administrators

    Hi @Kit-Bishop, if you do an oupgrade now, you should be able to upgrade to a firmware with the patches applied. Please let me know if it works.



  • @Boken-Lin Unfortunately, no it doesn't seem to work after a clean update to the latest release.

    The first issue is that there is no kmod-gpio-irq that I require - it is not available via opkg even after doing an opkg update - so I tried installing the version I had built using the OpenWrt cross compile environment (and which worked with the patched system image I had built and installed).

    I think i have tracked the problem down to the fact that there is no /sys/kernel/debug/gpio-irq file. The GPIO irq handling works by writing to this file.

    I am trying to track down what I had installed in my separately compiled image that would have created this file.

    If you have any info on this, I would be interested to hear. meanwhile, I will try to keep working to track down what is different between the latest Omega build (for which GPIO irq does not work) and the system build that I produced (for which GPIO irq works)


  • administrators

    Hi @Kit-Bishop, It could have been that the patch did not get included in the build for whatever reason. I will work with @Lazar-Demin to sort it out tomorrow.



  • @Boken-Lin Thanks. Would be good if it was as simple as not having included the patch (it's this one: https://github.com/GBert/openwrt-misc/blob/master/gpio-test/src/patches-3.18/739-MIPS-ath79-add-gpio-irq-support.patch).
    Though, it will be essential also that kmod-gpio-irq be available via opkg as well.

    I'm probably about to take a break (it's getting to be evening here) - if I don't here anything more from you on this, I will keep looking tomorrow.


  • administrators

    hey @Kit-Bishop firmware b265 and later have kmod-gpio-irq and the gpio.c patch.
    I installed and ran gpio-test locally, the edge based interrupts do in fact get triggered!

    Btw, I made the gpio-test package available in the Onion package repo.

    Happy hacking!



  • @Lazar-Demin Cool :-) Thanks for quick feedback :-)

    I am currently on firmware b264 so will shortly upgrade and try again. Will report back when done



  • @Lazar-Demin Absolutely fantastic! Thank you very much :-)

    Have upgraded to b266 and everything works perfectly - including my GPIO IRQ and test program.

    My IRQ code is basically an extension to the code I have previously posted for new GPIO access (https://community.onion.io/topic/143/alternative-c-code-for-gpio-access) with the addition of IRQ handling capabilities.

    Because it may be of use to others, I will do the following:

    1. Send the test program and needed library with some basic documentation on its use in a separate post
    2. Later, update the package and details in https://community.onion.io/topic/143/alternative-c-code-for-gpio-access with the latest sources and full documentation

Log in to reply
 

Looks like your connection to Onion Community was lost, please wait while we try to reconnect.