Jump to content

sgjava

Members
  • Posts

    411
  • Joined

  • Last visited

Reputation Activity

  1. Like
    sgjava got a reaction from gounthar in XU4 h264_v4l2m2m ffmpeg encoding   
    Trying HK's image now with same configuration. Using Linux video 4.14.157-171 #1 SMP PREEMPT Wed Dec 4 08:21:54 -03 2019 armv7l armv7l armv7l GNU/Linux. I'll circle back once I test this out to get past my current need. Looks like hardware encoding is embedded already as well.
     
  2. Like
    sgjava got a reaction from gounthar in XU4 h264_v4l2m2m ffmpeg encoding   
    Just a follow up while trying to run 3 cameras on the UX4 like I was doing with HK's Ubuntu release. Armbian always is showing a large amount of nice time. I'm not sure if this is the hardware encoder, but I'm not seeing this with HK's release. I'm also having issues where the XU4 just dies and shuts down. I might dig around in the logs, but there's definitely something up. I'll switch back to HK release and try the same configuration and see what happens.
     
    Armbian release:

     
    HK release:

  3. Like
    sgjava got a reaction from gounthar in XU4 h264_v4l2m2m ffmpeg encoding   
    Armbianmonitor: http://ix.io/24iC My end game is to use hardware h264 encoding for my security camera streams (using OpenCV, etc) . The first step is testing ffmpeg. It appears that all the necessary pieces are already present in the release I'm using. If I use:
     
    ffmpeg -i centaur_2.mpg -acodec aac -vcodec h264 -b:v 2M -pix_fmt nv21 test.mp4
     
    CPU stays below 12% and I get 44 FPS. Seems like hardware encoding is working here.
     
    If I use:
     
    ffmpeg -i centaur_2.mpg -acodec aac -vcodec h264_v4l2m2m -b:v 2M -pix_fmt nv21 test.mp4
     
    About the same performance, but the file is 10x larger!
     
    If I use:
     
    ffmpeg -i centaur_2.mpg -acodec aac -vcodec libx264 -b:v 2M -pix_fmt nv21 test.mp4
     
    About the same as h264. So it looks to me like h264_v4l2m2m is used by h264 and libx264 codecs?
     
    Linux 4.14.150-odroidxu4 #1 SMP PREEMPT Mon Oct 28 07:56:57 CET 2019 armv7l armv7l armv7l GNU/Linux BOARD=odroidxu4 BOARD_NAME="Odroid XU4" BOARDFAMILY=odroidxu4 BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=1221d592 VERSION=5.95 LINUXFAMILY=odroidxu4 BRANCH=default ARCH=arm IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm KERNEL_IMAGE_TYPE=zImage ffmpeg -encoders | grep 264 V..... libx264 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (codec h264) V..... libx264rgb libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 RGB (codec h264) V..... h264_omx OpenMAX IL H.264 video encoder (codec h264) V..... h264_v4l2m2m V4L2 mem2mem H.264 encoder wrapper (codec h264) V..... h264_vaapi H.264/AVC (VAAPI) (codec h264)  
  4. Like
    sgjava got a reaction from TonyMac32 in User Space IO is Python 3 and Java 8 bindings for user space GPIO, SPI, I2C, PWM and Serial interfaces   
    The main thing for me is I wanted something more portable than RPi.GPIO, so that I can run  the same code on multiple SBCs without coding to a Pi specific API. Plus I wanted to cover the JVM in addition to Python 3 and C. Now I can pick what language makes sense in the context of the project instead of the API driving that (i.e. RPi.GPIO == Python only). Secondly, by using libgpiod for GPIO I'm insulating myself from all the low level coding and making GPIO portable.
     
    To me it depends on the project. If I'm doing something from scratch (which I usually am) then I will gravitate to my library since I can port it to a different language or SBC easily. If something I'm working on has a RPi.GPIO or WiringPi dependency then I'll probably use those to save the effort and not reinvent the wheel. If I use luma.oled for instance then It's going to be a Python project. I can use Userspace IO's Python API for GPIO in addition to driving a OLED display with luma.oled.
  5. Like
    sgjava got a reaction from lanefu in Improve 'Support over Forum' situation   
    They manage OpenCV on github, so I think that would be great to continue there for Armbian. Jira is chock full of unnecessary complexity. We use it at work and you become a slave to the process instead of programming.  This is really the only method that really works http://programming-motherfucker.com
  6. Like
    sgjava got a reaction from TonyMac32 in Improve 'Support over Forum' situation   
    They manage OpenCV on github, so I think that would be great to continue there for Armbian. Jira is chock full of unnecessary complexity. We use it at work and you become a slave to the process instead of programming.  This is really the only method that really works http://programming-motherfucker.com
  7. Like
    sgjava got a reaction from TRS-80 in Adafruit CircuitPython   
    https://github.com/sgjava/userspaceio supports C, C++, Python and JVM (Java, Scala, Koltin, etc.). Do we really need another Python lib besides WiringPi and RPi.GPIO? Also, I have non-root access working for pretty much everything.
     
    Another thing, from looking at the CircuitPython site it appears to only support micro controllers at this point, not a full blown SBC. For this type of stuff I'm using NodeMCU with Lua which is mature and is hard to beat from a price/performance/usability perspective.
  8. Like
    sgjava got a reaction from TonyMac32 in Use GPIO on C2 with Mainline Kernel   
    @TonyMac32 OK, I get /dev/spidev0.0 now! I'll do a SPI loopback test tomorrow since I have to take it out of the server rack It's full now, but this gives you an idea:
     

  9. Like
    sgjava got a reaction from nik-ii in Use GPIO on C2 with Mainline Kernel   
    @nik-ii OK, I had some time to play around with my C2 which already had Armbian Stretch installed:
     
    Linux hostname 4.18.8-odroidc2 #264 SMP PREEMPT Wed Sep 19 12:35:18 CEST 2018 aarch64 GNU/Linux
     
    armbian-config has no Hardware menu, but it looks like GPIO and I2C are already enabled:
     
    ls /dev/gpio* /dev/i2c* /dev/spi*
    ls: cannot access '/dev/spi*': No such file or directory
    /dev/gpiochip0  /dev/gpiochip1  /dev/i2c-0  /dev/i2c-1
     
    If you go to the Odroid C2 wiki you can follow the steps to enable SPI:
     
    sudo su -
     
    modprobe spidev
    modprobe spi_gpio
    modprobe: FATAL: Module spi_gpio not found in directory /lib/modules/4.18.8-odroidc2
    modprobe spi_bitbang
     
    lsmod | grep spi
    spi_bitbang            16384  0
    spidev                 20480  0
     
    ls /dev/spi*
    ls: cannot access '/dev/spi*': No such file or directory
     
    I'm not sure what's going on here because this works with the HardKernel OS images. I'm actually using my C2 as a Jenkins CI server, but I did play around and made sure gpio, i2c and spi worked. I believe that was a 3.x kernel though @Igor may be able to point you in a better direction to get SPI cranking.
     
    There are other drivers, but I'm not sure which one to use:
     
    ls /lib/modules/4.18.8-odroidc2/kernel/drivers/spi
    spi-bitbang.ko    spi-butterfly.ko  spidev.ko  spi-lm70llp.ko  spi-meson-spifc.ko
     
     
  10. Like
    sgjava got a reaction from nik-ii in Use GPIO on C2 with Mainline Kernel   
    @nik-ii I actually have a C2 and I think I just loaded mainline on it a few weeks ago.  I'll check tonight, but if your SBC is using mainline then it should work.  With armbian-config you need to enable SPI, I2C, etc. I'll reply back here later with C2 specific info.
     
    Note from your pic that GPIO is showing up.
  11. Like
    sgjava got a reaction from esbeeb in Learning from DietPi!   
    As a dev I vote to keep the dev packages in. Sure is nice to have the build tools (even git client) installed even if things like libtool and pkg-config are missing from the base. If you are going for a minimal install I understand stripping all this stuff out, but I'm not sure how important it is to have a 700K vs 1.6 G image in today's terms. As @tkaiser points out most people have moved on beyond 4G SD cards. I've been using 32G for years and the price/performance is good for what I need it for.
     
    I've have some home made security cameras that write/read/delete 100s of movies and images a day 24/7 for years without failure. I realize there may be more intensive usages scenarios (more write intensive), but at the current pricing levels I'll toss the SD out every few years if I have to. As with all things the lowest common denominator or race to the bottom isn't always the best strategy. Stability and standardization are more important to me then a little extra RAM, a little more SD life, etc. Not that these are not important, but the bigger picture I think is more important to focus on.
  12. Like
    sgjava got a reaction from guidol in C2 mainline networking issues   
    @Igor I fixed this by using armbian-config, clearing interfaces and using /etc/network/interfaces. Now I can reboot with a static address. With NanoPi Duo I had to remove netplan and use ifupdown for eth0, but the xradio wifi stuff seems to be missing from the kernel (modules, etc.). But in essence they exhibited the same issue with eth0.
  13. Like
    sgjava got a reaction from WarHawk_AVG in Build libgpiod the "New GPIO Interface for User Space"   
    https://github.com/sgjava/userspaceio is my github and libgopid is at https://github.com/brgl/libgpiod
  14. Like
    sgjava got a reaction from gounthar in Luma.OLED on NanoPi Duo with SPI?   
    I figured it out. I had it wired to MI instead of MO! I'll do a write up once I have everything working the way I want.
  15. Like
    sgjava got a reaction from guidol in CPU governor stays at ondemand   
    OK, I did the following:
    cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=240000 MAX_SPEED=1008000 GOVERNOR=conservative sudo rm /lib/systemd/system/ondemand.service sudo systemctl daemon-reload sudo reboot cpufreq-info -o minimum CPU frequency - maximum CPU frequency - governor CPU 0 240000 kHz ( 20 %) - 1008000 kHz ( 84 %) - conservative CPU 1 240000 kHz ( 20 %) - 1008000 kHz ( 84 %) - conservative CPU 2 240000 kHz ( 20 %) - 1008000 kHz ( 84 %) - conservative CPU 3 240000 kHz ( 20 %) - 1008000 kHz ( 84 %) - conservative
  16. Like
    sgjava got a reaction from gounthar in NanoPi Duo + I2C SSD1306 + Luma.OLED = Cool   
    The Luma library allows you to display text, graphics, animation, etc. on multiple display types. Here I will describe the easiest one to configure which is Luma.OLED and the I2C version of the SSD1306. You can find these displays on EBay and Amazon for less than $10 US each (you can get them for less than $3 US if you order from China, but it might not show up). I've configured Luma on many SBCs and it's my go to library if I need a small display for projects.
     

     
    Requirements
    NanoPi Duo (I used V1.0 board with 512 MB RAM) flashed with Armbian image. This will work with or without the mini shield. Small nylon nuts, bolts and standoffs if you want to mount display I2C OLED display (check http://luma-oled.readthedocs.io/en/latest/hardware.html) 4 female to female jumper wires If you want to configure wifi the easy way just edit the following file on the SD sudo nano /media/username/43296f0d-fc9e-4cec-b3bf-f335fc72f371/etc/network/interfaces and add:
    allow-hotplug wlan0 iface wlan0 inet static address 192.168.1.69 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.1 wpa-ssid your_ssid wpa-psk your_password Comment out the eth0 stuff. You can do it the hard way with the debug serial interface though if you want When I ordered my Duos I forgot to order the USB dongle, so I would have been out of luck otherwise. Boot up and configure the Duo the way you like, power off and wire up the display as follows:
    VCC to either 5Vin or 3V3 GND to GND SCL to SCL SDA to SDA Power up Duo and configure I2C:
    sudo nano /boot/armbianEnv.txt and add i2c0 to overlays= sudo apt-get install i2c-tools sudo usermod -a -G i2c username (non-root user you created) sudo i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- If you see the 3c on i2c0 then you are in business. Let's install Luma.OLED:
    sudo apt-get install python-dev python-pip libfreetype6-dev libjpeg-dev sudo -H pip install --upgrade pip sudo apt-get purge python-pip sudo -H pip install --upgrade pip setuptools sudo -H pip install --upgrade luma.oled sudo -H pip uninstall RPi.GPIO (this will not work on Duo and is not needed for I2C) OK, let's create a simple demo program to make sure things are working nano i2chello.py:
    import time from luma.core.interface.serial import i2c from luma.core.render import canvas from luma.oled.device import ssd1306 serial = i2c(port=0, address=0x3C) device = ssd1306(serial) with canvas(device) as draw: draw.rectangle(device.bounding_box, outline="white") draw.text((3, 3), "Hello", fill="white") time.sleep(10) And you should see (screen shot from the Luma emulator):
     

     
    Now we can install the Luma examples:
    sudo apt-get install git-core libsdl-dev libportmidi-dev libsdl-ttf2.0-dev libsdl-mixer1.2-dev libsdl-image1.2-dev
    git clone https://github.com/rm-hull/luma.examples.git
    cd luma.examples
    sudo -H pip install -e .
    Let's run an example: sudo python examples/invaders.py -d ssd1306 --i2c-port 0 --i2c-address 0x3c
  17. Like
    sgjava got a reaction from chwe in ArmbianIO API proposal   
    @chwe I don't remember why I removed this. I just added it back. Try again and it should register with Python now.
  18. Like
    sgjava got a reaction from vlad59 in Learning from DietPi!   
    As a dev I vote to keep the dev packages in. Sure is nice to have the build tools (even git client) installed even if things like libtool and pkg-config are missing from the base. If you are going for a minimal install I understand stripping all this stuff out, but I'm not sure how important it is to have a 700K vs 1.6 G image in today's terms. As @tkaiser points out most people have moved on beyond 4G SD cards. I've been using 32G for years and the price/performance is good for what I need it for.
     
    I've have some home made security cameras that write/read/delete 100s of movies and images a day 24/7 for years without failure. I realize there may be more intensive usages scenarios (more write intensive), but at the current pricing levels I'll toss the SD out every few years if I have to. As with all things the lowest common denominator or race to the bottom isn't always the best strategy. Stability and standardization are more important to me then a little extra RAM, a little more SD life, etc. Not that these are not important, but the bigger picture I think is more important to focus on.
  19. Like
    sgjava got a reaction from Tido in Learning from DietPi!   
    As a dev I vote to keep the dev packages in. Sure is nice to have the build tools (even git client) installed even if things like libtool and pkg-config are missing from the base. If you are going for a minimal install I understand stripping all this stuff out, but I'm not sure how important it is to have a 700K vs 1.6 G image in today's terms. As @tkaiser points out most people have moved on beyond 4G SD cards. I've been using 32G for years and the price/performance is good for what I need it for.
     
    I've have some home made security cameras that write/read/delete 100s of movies and images a day 24/7 for years without failure. I realize there may be more intensive usages scenarios (more write intensive), but at the current pricing levels I'll toss the SD out every few years if I have to. As with all things the lowest common denominator or race to the bottom isn't always the best strategy. Stability and standardization are more important to me then a little extra RAM, a little more SD life, etc. Not that these are not important, but the bigger picture I think is more important to focus on.
  20. Like
    sgjava got a reaction from Technicavolous in User Space IO is Python 3 and Java 8 bindings for user space GPIO, SPI, I2C, PWM and Serial interfaces   
    Edit: User Space IO depracated. Use Java Periphery instead https://github.com/sgjava/java-periphery
     
    https://github.com/sgjava/userspaceio
     
    After a lot of work and testing I have produced the User Space IO project! It provides Python 3 and Java 8 bindings for Linux user space GPIO, SPI, I2C, PWM and Serial interfaces. This allows cross SBC and cross language development using a common API. I took two best of breed C APIs for Linux user space libgpiod and c-periphery and produced CFFI bindings for Python and JNA bindings for Java. Since all the bindings closely match the C API it's easy to move from language to language. The side effect of using the Java library is that it should work with many different JVM based languages. How about creating your programs in Kotlin or Scala for instance?
     
    GPIO access uses the new gpiod interface and not the deprecated sysfs interface using libgpiod v1.1 (head from git repo). GPIO, SPI, I2C and serial interfaces expose all the low level functionality. I have added some helper methods for handling repetitive functions like building I2C messages, reading words from two registers, etc. You can of course go as low level as you need to. Please use Github to post any issues, pull requests, etc. I have tested Nano Pi Duo for 32 bit and NanoPi Neo +2 for 64 bit compatibility. I'll test more SBCs as I have time. Also, I have deleted https://github.com/sgjava/libgpiod-extra since User Space IO supersedes it.
     
    Based of some of the questions I had in the past please note the following:
    gpiod_ctxless_event_loop_multiple can handle GPIO interrupts Miscellaneous GPIO request flags GPIOD_LINE_REQUEST_FLAG_OPEN_DRAIN, GPIOD_LINE_REQUEST_FLAG_OPEN_SOURCE, GPIOD_LINE_REQUEST_FLAG_ACTIVE_LOW Non-root access using rc.local. Demo program using hardware PWM to flash LED:
     
  21. Like
    sgjava got a reaction from lanefu in User Space IO is Python 3 and Java 8 bindings for user space GPIO, SPI, I2C, PWM and Serial interfaces   
    Edit: User Space IO depracated. Use Java Periphery instead https://github.com/sgjava/java-periphery
     
    https://github.com/sgjava/userspaceio
     
    After a lot of work and testing I have produced the User Space IO project! It provides Python 3 and Java 8 bindings for Linux user space GPIO, SPI, I2C, PWM and Serial interfaces. This allows cross SBC and cross language development using a common API. I took two best of breed C APIs for Linux user space libgpiod and c-periphery and produced CFFI bindings for Python and JNA bindings for Java. Since all the bindings closely match the C API it's easy to move from language to language. The side effect of using the Java library is that it should work with many different JVM based languages. How about creating your programs in Kotlin or Scala for instance?
     
    GPIO access uses the new gpiod interface and not the deprecated sysfs interface using libgpiod v1.1 (head from git repo). GPIO, SPI, I2C and serial interfaces expose all the low level functionality. I have added some helper methods for handling repetitive functions like building I2C messages, reading words from two registers, etc. You can of course go as low level as you need to. Please use Github to post any issues, pull requests, etc. I have tested Nano Pi Duo for 32 bit and NanoPi Neo +2 for 64 bit compatibility. I'll test more SBCs as I have time. Also, I have deleted https://github.com/sgjava/libgpiod-extra since User Space IO supersedes it.
     
    Based of some of the questions I had in the past please note the following:
    gpiod_ctxless_event_loop_multiple can handle GPIO interrupts Miscellaneous GPIO request flags GPIOD_LINE_REQUEST_FLAG_OPEN_DRAIN, GPIOD_LINE_REQUEST_FLAG_OPEN_SOURCE, GPIOD_LINE_REQUEST_FLAG_ACTIVE_LOW Non-root access using rc.local. Demo program using hardware PWM to flash LED:
     
  22. Like
    sgjava got a reaction from lanefu in Using Python, CFFI and libgpiod for cross SBC GPIO access   
    On my journey to finding the best solution for cross SBC/cross language GPIO support I went through the same issues as Python by the C side author did it seems and landed on CFFI. This is faster than ctypes and seem more natural to program with. ctypesgen (the code generator) doen't really support Python 3, so I've hit a dead end there. It seems like JNA is still the best choice for Java bindings, so I'm sticking with that for now. In any event I threw together a button press app that uses CFFI and libgrpiod. I'll be updating my bindings project to support this soon.
     
    libgpiod version 1.1.devel
    Name: gpiochip1, label: 1f02c00.pinctrl, lines: 32
    Press button within 5 seconds
    Falling edge timestamp 02/10/2018 19:49:05
    """ Test blocking event using built in button ------------- Should work on any board with a button built in. Just change chip and line value as needed. """ import sys, time from argparse import * from cffi import FFI parser = ArgumentParser() parser.add_argument("--chip", help="GPIO chip number (default 1 '/dev/gpiochip1')", type=int, default=1) parser.add_argument("--line", help="GPIO line number (default 3 button on NanoPi Duo)", type=int, default=3) args = parser.parse_args() ffi = FFI() # Specify each C function, struct and constant you want a Python binding for # Copy-n-paste with minor edits ffi.cdef(""" enum { GPIOD_LINE_EVENT_RISING_EDGE, GPIOD_LINE_EVENT_FALLING_EDGE, }; struct timespec { long tv_sec; long tv_nsec; }; struct gpiod_line { unsigned int offset; int direction; int active_state; bool used; bool open_source; bool open_drain; int state; bool up_to_date; struct gpiod_chip *chip; int fd; char name[32]; char consumer[32]; }; struct gpiod_chip { struct gpiod_line **lines; unsigned int num_lines; int fd; char name[32]; char label[32]; }; struct gpiod_line_event { struct timespec ts; int event_type; }; const char *gpiod_version_string(void); struct gpiod_chip *gpiod_chip_open_by_number(unsigned int num); struct gpiod_line *gpiod_chip_get_line(struct gpiod_chip *chip, unsigned int offset); int gpiod_line_request_falling_edge_events(struct gpiod_line *line, const char *consumer); int gpiod_line_event_wait(struct gpiod_line *line, const struct timespec *timeout); int gpiod_line_event_read(struct gpiod_line *line, struct gpiod_line_event *event); void gpiod_line_release(struct gpiod_line *line); void gpiod_chip_close(struct gpiod_chip *chip); """) lib = ffi.dlopen("libgpiod.so") print "libgpiod version %s" % ffi.string(lib.gpiod_version_string()) gpiod_chip = lib.gpiod_chip_open_by_number(args.chip) # Make sure GPIO chip opened if gpiod_chip != ffi.NULL: print("Name: %s, label: %s, lines: %d" % (ffi.string(gpiod_chip.name), ffi.string(gpiod_chip.label), gpiod_chip.num_lines)) gpiod_line = lib.gpiod_chip_get_line(gpiod_chip, args.line) # Verify we have line if gpiod_line != ffi.NULL: consumer = sys.argv[0][:-3] if lib.gpiod_line_request_falling_edge_events(gpiod_line, consumer) == 0: timespec = ffi.new("struct timespec*") timespec.tv_sec = 5 print("Press button within 5 seconds") rc = lib.gpiod_line_event_wait(gpiod_line, timespec) if rc == 0: print("Timed out") elif rc == 1: event = ffi.new("struct gpiod_line_event*") # Read event off queue lib.gpiod_line_event_read(gpiod_line, event) if event.event_type == lib.GPIOD_LINE_EVENT_RISING_EDGE: print("Rising edge timestamp %s" % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(event.ts.tv_sec))) else: print("Falling edge timestamp %s" % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(event.ts.tv_sec))) else: print("Unable request falling edge for line %d" % args.line) lib.gpiod_line_release(gpiod_line) else: print("Unable to get line %d" % args.line) lib.gpiod_chip_close(gpiod_chip) else: print("Unable to open chip %d" % args.chip)  
  23. Like
    sgjava got a reaction from MitchD in Using Python, CFFI and libgpiod for cross SBC GPIO access   
    On my journey to finding the best solution for cross SBC/cross language GPIO support I went through the same issues as Python by the C side author did it seems and landed on CFFI. This is faster than ctypes and seem more natural to program with. ctypesgen (the code generator) doen't really support Python 3, so I've hit a dead end there. It seems like JNA is still the best choice for Java bindings, so I'm sticking with that for now. In any event I threw together a button press app that uses CFFI and libgrpiod. I'll be updating my bindings project to support this soon.
     
    libgpiod version 1.1.devel
    Name: gpiochip1, label: 1f02c00.pinctrl, lines: 32
    Press button within 5 seconds
    Falling edge timestamp 02/10/2018 19:49:05
    """ Test blocking event using built in button ------------- Should work on any board with a button built in. Just change chip and line value as needed. """ import sys, time from argparse import * from cffi import FFI parser = ArgumentParser() parser.add_argument("--chip", help="GPIO chip number (default 1 '/dev/gpiochip1')", type=int, default=1) parser.add_argument("--line", help="GPIO line number (default 3 button on NanoPi Duo)", type=int, default=3) args = parser.parse_args() ffi = FFI() # Specify each C function, struct and constant you want a Python binding for # Copy-n-paste with minor edits ffi.cdef(""" enum { GPIOD_LINE_EVENT_RISING_EDGE, GPIOD_LINE_EVENT_FALLING_EDGE, }; struct timespec { long tv_sec; long tv_nsec; }; struct gpiod_line { unsigned int offset; int direction; int active_state; bool used; bool open_source; bool open_drain; int state; bool up_to_date; struct gpiod_chip *chip; int fd; char name[32]; char consumer[32]; }; struct gpiod_chip { struct gpiod_line **lines; unsigned int num_lines; int fd; char name[32]; char label[32]; }; struct gpiod_line_event { struct timespec ts; int event_type; }; const char *gpiod_version_string(void); struct gpiod_chip *gpiod_chip_open_by_number(unsigned int num); struct gpiod_line *gpiod_chip_get_line(struct gpiod_chip *chip, unsigned int offset); int gpiod_line_request_falling_edge_events(struct gpiod_line *line, const char *consumer); int gpiod_line_event_wait(struct gpiod_line *line, const struct timespec *timeout); int gpiod_line_event_read(struct gpiod_line *line, struct gpiod_line_event *event); void gpiod_line_release(struct gpiod_line *line); void gpiod_chip_close(struct gpiod_chip *chip); """) lib = ffi.dlopen("libgpiod.so") print "libgpiod version %s" % ffi.string(lib.gpiod_version_string()) gpiod_chip = lib.gpiod_chip_open_by_number(args.chip) # Make sure GPIO chip opened if gpiod_chip != ffi.NULL: print("Name: %s, label: %s, lines: %d" % (ffi.string(gpiod_chip.name), ffi.string(gpiod_chip.label), gpiod_chip.num_lines)) gpiod_line = lib.gpiod_chip_get_line(gpiod_chip, args.line) # Verify we have line if gpiod_line != ffi.NULL: consumer = sys.argv[0][:-3] if lib.gpiod_line_request_falling_edge_events(gpiod_line, consumer) == 0: timespec = ffi.new("struct timespec*") timespec.tv_sec = 5 print("Press button within 5 seconds") rc = lib.gpiod_line_event_wait(gpiod_line, timespec) if rc == 0: print("Timed out") elif rc == 1: event = ffi.new("struct gpiod_line_event*") # Read event off queue lib.gpiod_line_event_read(gpiod_line, event) if event.event_type == lib.GPIOD_LINE_EVENT_RISING_EDGE: print("Rising edge timestamp %s" % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(event.ts.tv_sec))) else: print("Falling edge timestamp %s" % time.strftime('%m/%d/%Y %H:%M:%S', time.localtime(event.ts.tv_sec))) else: print("Unable request falling edge for line %d" % args.line) lib.gpiod_line_release(gpiod_line) else: print("Unable to get line %d" % args.line) lib.gpiod_chip_close(gpiod_chip) else: print("Unable to open chip %d" % args.chip)  
  24. Like
    sgjava got a reaction from gnasch in Build libgpiod the "New GPIO Interface for User Space"   
    This has been replaced by: User Space IO get more details on this thread.
     

     
    Well, it's time to say goodbye to sysfs and hello to libgpiod! @zador.blood.stained pointed me in the right direction, but you need to do one little hack I'll explain below involving compiler_types.h. I tested this on a NanoPi Duo, but it should work on any mainline Armbian release (and other distros as well) as long as the kernel is >= 4.8. Try ls /dev/gpiochip* and see if anything is listed. If so, then proceed.
     
    I'm continuing work on my Github site https://github.com/sgjava/libgpiod-extra, so please report any issues there. There is an Armbian install script that automates the steps below I generated the Python wrapper, but there's a lot of functions to test, so I'm not sure of the quality. I'm working on some simple Python tests.
    sudo armbian-config, Software, Headers sudo apt-get install libtool pkg-config git clone https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git cd libgpiod mkdir -p include/linux cp /usr/src/linux-headers-$(uname -r)/include/linux/compiler_types.h include/linux/. ./autogen.sh --enable-tools=yes --prefix=/usr/local CFLAGS="-I/usr/src/linux-headers-$(uname -r)/include/uapi -Iinclude" make sudo make install sudo ldconfig Let's try some commands:
     
    sudo gpiodetect
     
    gpiochip0 [1c20800.pinctrl] (224 lines)
    gpiochip1 [1f02c00.pinctrl] (32 lines)
     
    sudo gpioinfo | grep "\[used\]"
     
        line  10:      unnamed "nanopi:blue:status" output active-high [used]
        line 166:      unnamed         "cd"   input  active-high [used]
        line 202:      unnamed  "interrupt"   input  active-high [used]
        line 205:      unnamed      "reset"  output   active-low [used]
        line   6:      unnamed          "?"  output  active-high [used]
        line   7:      unnamed   "vcc-wifi"  output  active-high [used]
        line  10:      unnamed "nanopi:green:pwr" output active-high [used]
     
    Notice how it found the Duo's built in LEDs
     
    Now let's test the Duo's built in button (press and release 3 times):
     
    sudo gpiomon --num-events=3 --rising-edge gpiochip1 3
     
    event:  RISING EDGE offset: 3 timestamp: [1516774143.944174870]
    event:  RISING EDGE offset: 3 timestamp: [1516774145.123474395]
    event:  RISING EDGE offset: 3 timestamp: [1516774145.987531088]
     
    Wire up LED (the normal way) and use Duo's IOG11 then to turn on and off:
     
    sudo gpioset gpiochip0 203=0
    sudo gpioset gpiochip0 203=1
     
    Python code
    import time from libgpiod.libgpiod import * chip = gpiod_chip_open("/dev/gpiochip0") line = gpiod_chip_get_line(chip, 203) # The will set line for output and set initial value (LED on) if gpiod_line_request_output(line, "test", 0) == 0: time.sleep(3) # LED off gpiod_line_set_value(line, 1) gpiod_line_release(line) gpiod_chip_close(chip) More reading at https://www.cnx-software.com/2017/11/03/learn-more-about-linuxs-new-gpio-user-space-subsystem-libgpiod and https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/README. Maybe @Larry Bank will work on ArmbianIO II It looks like in the old Github site there was a milestone to create Python and C++ wrappers https://github.com/brgl/libgpiod/milestone/3. Once I learn more about libgpiod I may just generate them like I did for ArmbianIO.
  25. Like
    sgjava got a reaction from MitchD in Build libgpiod the "New GPIO Interface for User Space"   
    OK, I whipped up a simple Python program using a thread to wait for an edge event while the main program is doing something else. https://github.com/sgjava/libgpiod-extra/blob/master/python/buttonthread.py
     
    You can pass --chip with GPIO chip number and --line for the line (pin) where your built in button is located. Really no need for IRQs since the events are queued and the thread is waiting on the edge to happen. You can use the thread to do a callback using OOP and an Observer pattern. This is more elegant than having C callback to Python, Java, etc.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines