Jump to content

sgjava

Members
  • Posts

    411
  • Joined

  • Last visited

Everything posted by sgjava

  1. Actually I want to update brightness, but I may want to update trigger as well (sudo works): echo 0 > /sys/class/leds/nanopi\:green\:pwr/brightness /sys/class/leds/nanopi:green:pwr/brightness: Permission denied
  2. I'm looking for udev rules or some other way to read system LEDs without sudo. I tried https://github.com/todbot/blink1/blob/master/linux/51-blink1.rules, but I suspect it's not 100% what I need for the Duo.
  3. @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.
  4. 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.
  5. @Igor libgpiod author said they are supporting kernel >= 5.5.0 in master and 1.5.x branch. I had to use the 1.4.x branch because of this. Looking forward to >= 5.5.0 kernel!
  6. @martinayotte Can you give me and example of this? I saved off the old dtb and can try the delete node on that. Would be better if you do not have to decompile/remove/compile.
  7. GPIO tested (led blink, button presses, callbacks, etc). SPI should be easy to test with a loopback and I'll test hardware PWM with the same LED. I had to remove section from dtb that used the built in button for kernel shutdown, so I didn't have to wire up one
  8. 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. OK, I'll need to remember how to decompile and compile the dtb. I've done it before when I wanted to use OTG port on Duo and had to use the FriendlyElec dtb.
  10. I noticed with the latest bionic image on the Duo it does a soft shutdown when you use the built in button. The problem is I use this button for my own uses. Can this feature be disabled and relinquish control of the button? gpioinfo | grep k1 line 3: unnamed "k1" input active-low [used]
  11. @TonyMac32 @Tido Userspace IO has been brought up to date. I still need to do individual component tests, but everything generates/compiles fine now. c-periphery API changed slightly, but that broke all the wrapping code. c-periphery now has a separate step besides open/close which is new/free. I just baked new/free into my open/close wrapper, so existing code will not break. To summarize you can now: Use 5.x kernels Use latest Zulu JDK Use latest JNA jars (for Java wrappers) Updated CFFI for c-periphery Use github issues for build/runtime related stuff https://github.com/sgjava/userspaceio/issues
  12. OK, I have c-periphery bindings working, but it looks like the project has been refactored, so the demo code broke. Fixing that now.
  13. @TonyMac32 I needed to bring things up to date any ways. A lot changed in a couple years 5.x kernel, library upgrades, Ubuntu updates, etc. It's amazing though that the install scripts held up pretty good. Oracle was always a pain in how they lock down downloading the JDK. Once they no longer had ARM releases after JDK 8, I switched to Zulu which is based on OpenJDK.
  14. @Tido Fundamentally, I wrap libgpiod and c-periphery as to provide Java and Python wrappers. Since libgpiod and c-periphery are already C/C++ there no need for a new C/C++ API. I used CFFI to generate Python interface to libgpiod, but there was no need after the author released his own Python API. I still use CFFI for c-periphery and pwm Python wrappers. The documentation is pretty clear. Look at the example code libgpiod and c-periphery are documented in their own projects, so there no need to duplicate that in my project. For instance, the libgpiod Python LED test https://github.com/sgjava/userspaceio/blob/master/libgpiod/python/src/ledtest.py. I have examples for each subproject. There's really no need for a matching layer. Larry did that to keep the pin numbers consistent. If you really wanted to do something like that it would be a layer above Userspace IO. I rely on kernel userspace, so there's no reliance on things like a hacked up RPi.GPIO, etc.
  15. @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)
  16. @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.
  17. 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.
  18. And the final result. This will encode an OpenCV numpy format image using hardware encoding. https://github.com/kkroening/ffmpeg-python/issues/301
  19. 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
  20. 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.
  21. OK, so I'm seeing the same behavior with HK's image. I have sample code in my OpenCV install script. https://github.com/sgjava/install-opencv/blob/master/opencv-python/codeferm/writer.py just takes a source video and encodes it to whatever Four CC is set. If I use X264 or H264 I get: %Cpu(s): 9.9 us, 1.1 sy, 24.6 ni, 63.2 id, 0.0 wa, 1.0 hi, 0.2 si, 0.0 st 2019-12-15 12:47:40,293 INFO writer OpenCV 4.2.0-pre 2019-12-15 12:47:40,294 INFO writer Input file: ../../resources/traffic.mp4 2019-12-15 12:47:40,294 INFO writer Output file: ../../output/writer-python.avi 2019-12-15 12:47:40,354 INFO writer Resolution: 480x360 2019-12-15 12:47:52,655 INFO writer 925 frames 2019-12-15 12:47:52,656 INFO writer 75.3 FPS, elapsed time: 12.29 seconds 859844 Dec 15 12:53 writer-python.avi With XVID (MP4 simple profile) I get: %Cpu(s): 9.9 us, 0.4 sy, 0.0 ni, 89.1 id, 0.0 wa, 0.5 hi, 0.0 si, 0.0 st 2019-12-15 12:50:05,547 INFO writer OpenCV 4.2.0-pre 2019-12-15 12:50:05,547 INFO writer Input file: ../../resources/traffic.mp4 2019-12-15 12:50:05,547 INFO writer Output file: ../../output/writer-python.avi 2019-12-15 12:50:05,608 INFO writer Resolution: 480x360 2019-12-15 12:50:21,139 INFO writer 925 frames 2019-12-15 12:50:21,139 INFO writer 59.6 FPS, elapsed time: 15.52 seconds 3025586 Dec 15 12:50 writer-python.avi I love the smaller file I get with H264, but the CPU overhead is much larger than I though it would be using hardware encoding. I'm going to play around with ffmpeg directly and see if I'm seeing the same issues.
  22. 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.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines