sgjava

Members
  • Posts

    329
  • Joined

  • Last visited

Reputation Activity

  1. Like
    sgjava got a reaction from lanefu in Java Periphery released!   
    Java Periphery has finally been released! Java Periphery is a high performance library for GPIO, LED, PWM, SPI, I2C, MMIO and Serial peripheral I/O interface access in userspace Linux. This will replace User Space IO. I'm seeing GPIO write speeds of 500K/s from userspace. Compared to User Space IO and libgopid speeds of 2K/s. I switched from JNA wrapper generation to JNI wrapper generation. The build process is much simpler (only single install.sh) and building libgpiod is no longer required. The API follows c-periphery, python-periphery and lua-periphery. This should cover the widest array of SBCs and languages around.
     
    Java Periphery should work on Armbian/Ubuntu/Debian, but also other non-Armbian distributions. If you run into issues please use Github issues to report.
     
    Nano Pi Duo
    13:30:43.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 13:31:23.062 [main] INFO com.codeferm.periphery.demo.GpioPerf - 500613.25 writes per second 13:31:23.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 13:31:54.471 [main] INFO com.codeferm.periphery.demo.GpioPerf - 318440.91 reads per second Nano Pi Neo Plus 2
    15:06:51.946 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 15:07:22.522 [main] INFO com.codeferm.periphery.demo.GpioPerf - 654964.63 writes per second 15:07:22.524 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 15:07:46.696 [main] INFO com.codeferm.periphery.demo.GpioPerf - 413770.27 reads per second  
  2. Like
    sgjava got a reaction from devman in Java Periphery released!   
    Java Periphery has finally been released! Java Periphery is a high performance library for GPIO, LED, PWM, SPI, I2C, MMIO and Serial peripheral I/O interface access in userspace Linux. This will replace User Space IO. I'm seeing GPIO write speeds of 500K/s from userspace. Compared to User Space IO and libgopid speeds of 2K/s. I switched from JNA wrapper generation to JNI wrapper generation. The build process is much simpler (only single install.sh) and building libgpiod is no longer required. The API follows c-periphery, python-periphery and lua-periphery. This should cover the widest array of SBCs and languages around.
     
    Java Periphery should work on Armbian/Ubuntu/Debian, but also other non-Armbian distributions. If you run into issues please use Github issues to report.
     
    Nano Pi Duo
    13:30:43.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 13:31:23.062 [main] INFO com.codeferm.periphery.demo.GpioPerf - 500613.25 writes per second 13:31:23.065 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 13:31:54.471 [main] INFO com.codeferm.periphery.demo.GpioPerf - 318440.91 reads per second Nano Pi Neo Plus 2
    15:06:51.946 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running write test with 10000000 samples 15:07:22.522 [main] INFO com.codeferm.periphery.demo.GpioPerf - 654964.63 writes per second 15:07:22.524 [main] INFO com.codeferm.periphery.demo.GpioPerf - Running read test with 10000000 samples 15:07:46.696 [main] INFO com.codeferm.periphery.demo.GpioPerf - 413770.27 reads per second  
  3. Like
    sgjava got a reaction from Tido in Fast GPIO access   
    https://en.wikipedia.org/wiki/Bit_banging where you write you own protocols in software without the need for I2C, UART, SPI, etc. https://calcium3000.wordpress.com/2016/08/19/i2c-bit-banging-tutorial-part-i Thus with two GPIO pins I can simulate I2C. With the slower speeds, not so much. You can also do square wave 1 bit PCM sound too. I'm going to date myself, but I was doing this on a C64 in the 1980s. https://github.com/sgjava/garage/blob/master/commodore/c64/digisound/src/digisnd.asm Then you only need a simple piezoelectric speaker.
     
    There are probably a bunch of other uses, but this should give you an idea. Just the fact that I'm half the speed of Bulldog with many more platforms is a good thing. I was shooting for a generic high performance solution instead of coding directly to the GPIO chip like Bulldog.
  4. Like
    sgjava got a reaction from lanefu in Fast GPIO access   
    After working with sysfs and libgpiod as cross platform solutions I was wondering if there was a faster way using /dev/mem or mmio? I know this gets more bare metal and SBC specific, but for some things you may want absolute speed. https://opensource.com/life/16/4/bulldog-gpio-library for instance claims 1 MHz GPIO writes in Java. However it only supports 3 SBCs as you can see from https://github.com/SilverThings/bulldog. Is there a more generic way to do this and not lose performance? Using my generated JNA wrappers for libgpiod I get about 2K writes per second. In Python I think it's about 70K using libgpiod Python bindings. I realize you may not always need 1 MHz GPIO writes, but it would be neat to offer this in a more generic way.
  5. 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.
  6. 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. 
  7. 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. 
  8. 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.
  9. 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.
     
  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 @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.
  11. 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.
  12. 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
  13. 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)  
  14. 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.
  15. 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.
  16. 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
  17. 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  
  18. 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.
  19. 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.
     
  20. 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:

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