sgjava

Members
  • Content Count

    201
  • Joined

  • Last visited


Reputation Activity

  1. 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   
    @TonyMac32 @Tido @fourtyseven I've updated userspaceio to build libgpiod master branch. It requires >= 5.5.0 kernel which I install using armbian-config. Now you will be on the bleeding edge of libgpiod.
  2. Like
    sgjava got a reaction from Tido in User Space IO is Python 3 and Java 8 bindings for user space GPIO, SPI, I2C, PWM and Serial interfaces   
    @TonyMac32 @Tido I've gone through all the demo code and everything is working with the updated libraries. non-root access works with everything except PWM which has been a bear to figure out. Also added system LED library which includes triggers. I still need to work on some demos for LED triggers. 
  3. 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   
    @TonyMac32 @Tido I've gone through all the demo code and everything is working with the updated libraries. non-root access works with everything except PWM which has been a bear to figure out. Also added system LED library which includes triggers. I still need to work on some demos for LED triggers. 
  4. 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.
  5. Like
    sgjava got a reaction from aaditya in Providing MRAA as common GPIO Library as a Replacement for WiringPi   
    https://github.com/sgjava/userspaceio already does this, but using the latest userspace libraries. I took a peek at mraa and the gpio source uses sysfs which is deprecated. See https://blog.adafruit.com/2018/11/26/sysfs-is-dead-long-live-libgpiod-libgpiod-for-linux-circuitpython/ No need to bake this into Armbian in my opinion. Also, I can install Userspace IO on other Linux distributions besides Armbian, so I'm not limited to a distribution.
     
    This whole idea of mapping pins the same seems kind of silly to me since a lot of my SBCs have a variable number of GPIO pins, some have multiple I2C, some have multi purpose pins, etc. This is something that should be done a layer above the actual APIs and is trivial to implement (using a pin map or table).
     
    There's no wheel reinvention going on here. I started Userspace IO over 2 years ago and it still remains the only true cross SBC API (there is no need to detect board type). Basically if your kernel is > 4.8 and supports devices mapped to userspace then it should work. mraa has limited ARM support (Pi is the only ARM SBC supported that I have out of 10 different SBCs).
     
    As far as non-root access see https://github.com/sgjava/userspaceio#non-root-access
     
    I'd love to just install Linux and have everything working, but that's not reality now. I'm not dissing mraa, but it's not something I'd use personally.
     
  6. 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   
    @TonyMac32 @Tido I'm building a frankenboard to test all the code (I'll need to take a picture soon). Since there were a lot of things brought up to date a regression type test is required (at least in my mind). So far GPIO, PWM and SPI are working fine. I even added logic to turn on/off LED based on HC-SR501 input in Java. The only issue so far was on libgpiod chip close https://github.com/sgjava/userspaceio/issues/5, but this may go away once I can test libgpiod master branch on 5.5 kernel.
  7. Like
    sgjava reacted to martinayotte in NanoPi Duo disable shutdown button   
    It is better to use "-@" option on "dtc", this is to keep symbols. But it is only available on device-tree-compiler_1.4.7-3_arm64.deb or newer.
  8. Like
    sgjava got a reaction from karabek in NanoPi Duo disable shutdown button   
    For future reference:
    cd /boot/dtb sudo cp sun8i-h2-plus-nanopi-duo.dtb sun8i-h2-plus-nanopi-duo.dtb.old sudo dtc -@ -I dtb -O dts -o sun8i-h2-plus-nanopi-duo.dts sun8i-h2-plus-nanopi-duo.dtb sudo nano sun8i-h2-plus-nanopi-duo.dts (remove r_gpio_keys section) sudo dtc -@ -I dts -O dtb -o sun8i-h2-plus-nanopi-duo.dtb sun8i-h2-plus-nanopi-duo.dts reboot
  9. 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   
    @TonyMac32 OK the cffi stuff is failing, but that's all packaging (no compiles), so I hope that's easy to fix. The Java/JNA and libgpiod work so far (what's committed). libgpiod master branch requires >= 5.5.0 kernel to build.  The nanopi duo distro uses 5.3.9, so I used v1.4.x branch! Let me see if I can finish up the rest.
    sudo gpiodetect gpiochip0 [1c20800.pinctrl] (224 lines) gpiochip1 [1f02c00.pinctrl] (32 lines)  
  10. 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   
    @TonyMac32 I just flash a nanopi duo v1.1 and will go through the install. I know for a fact the Java JDK will need to be updated. I'll keep you updated.
  11. Like
    sgjava got a reaction from TonyMac32 in ArmbianIO API proposal   
    I've focused only on UserSpaceIO because it covers more of what I needed. Multi-language/multi-interfaces. I'll go in and do any updates since I'll have to switch over to Zulu JVM since Oracle isn't releasing ARM based JDKs.
  12. Like
    sgjava got a reaction from gounthar in XU4 h264_v4l2m2m ffmpeg encoding   
    And the final result. This will encode an OpenCV numpy format image using hardware encoding. https://github.com/kkroening/ffmpeg-python/issues/301
  13. Like
    sgjava got a reaction from gounthar in XU4 h264_v4l2m2m ffmpeg encoding   
    I ended up using ffmpeg-python since I know ffmpeg hardware encoding/decoding work. Unfortunately OpenCV doesn't allow a lot of flexibility on the video back end (VideoWriter). I'll end up using a ffmpeg adaptor for my security system since ffmpeg-python allows me to set vcodec and convert numpy arrays. To hardware encode h264 use:
    #!/usr/bin/env python import ffmpeg (     ffmpeg     .input('test.avi')     .output('out.mp4', vcodec='h264_v4l2m2m', pix_fmt='nv21', **{'b:v': 2000000})     .run() ) Output #0, mp4, to 'out.mp4': Metadata: encoder : Lavf57.83.100 Stream #0:0: Video: h264 (h264_v4l2m2m) (avc1 / 0x31637661), nv21, 1280x720, q=2-31, 2000 kb/s, 7 fps, 14336 tbn, 7 tbc Metadata: encoder : Lavc57.107.100 h264_v4l2m2m  
  14. Like
    sgjava got a reaction from gounthar in XU4 h264_v4l2m2m ffmpeg encoding   
    Using ffmpeg -i motion-19-05-10.avi -an -vcodec h264_v4l2m2m -b:v 2M -pix_fmt nv21 test.mp4 I get the results I expected. Hardware encoding works fine. The key is to look for Stream #0:0 -> #0:0 (mpeg4 (mpeg4_v4l2m2m) -> h264 (h264_v4l2m2m)). The issue with the CPU nice time was caused by OpevCV using the software H264 encorder/decoder. I need to look for a way for OpenCV to use the hardware encoder for video encoding.
     
    Basically h264_v4l2m2m is working as expected in HK's image, so it should work the same way in Armbian.
  15. 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.
     
  16. 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:

  17. 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)  
  18. 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.
  19. 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
  20. 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
  21. Like
    sgjava got a reaction from Tido 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.
  22. 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:
     

  23. 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
     
     
  24. 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.
  25. 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.