-
Posts
411 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Community Map
Everything posted by sgjava
-
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
-
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.
-
@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.
-
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.
-
Will try this tonight...
-
@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.
-
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
-
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.
-
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]
-
@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
-
@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.
-
@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.
-
@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)
-
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.
-
-
And the final result. This will encode an OpenCV numpy format image using hardware encoding. https://github.com/kkroening/ffmpeg-python/issues/301
-
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
-
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.
-
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.
-
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.