sgjava

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:

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)

I did some messing around and switched to a 32GB SD (from 64GB, but same exact features as https://www.amazon.com/SanDisk-Ultra-microSDXC-Memory-Adapter/dp/B073JYVKNX) and it reboots fine now. FYI Odroid's image exhibits the same exact hang behavior ubuntu-18.04.3-4.14-minimal-odroid-xu4-20190910.img using 64GB SD. It was working fine with the 64GB SD, but with an older version of Odroid's image.

I just installed Armbian_5.90_Odroidxu4_Ubuntu_bionic_default_4.14.127.img which will hang on sudo reboot (fan keeps spinning, no blue heartbeat led). I have another XU4 runnig the same version without the reboot issue. Armbianmonitor info uploded.

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.

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

Yea, I understand trying to consolidate behind a single library, but I prefer using a single API and wrapping that with whatever language I want. It's a matter of perspective I guess. For beginners it may make sense to make it easy to use. @TonyMac32 The Java code performs pretty well using JNA instead of JNI.

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.

@adafruit what library are you using on the C2 for GPIO/I2C/SPI, etc?

@Igor thanks for getting that in!

I've had success with NanoPi Duo v1.1 and using the OTG port. I power off the rail instead of OTG port. The thing is I use the FriendlyElec DTB as the Armbian one doesn't support the OTG port. Now I'm using a different USB camera than you, but that may give you some config ideas. Also, I'd try the official FriendlyElec image and make sure it works.

@TonyMac32 ESP8266 Module ESP-12E NodeMcu is what is shown in the picture. There's decent IDEs and Lua is pretty easy to pick up. Having the built in USB serial interface makes it easy to program/power.

@TonyMac32 Correct, check the C1 wiki https://wiki.odroid.com/odroid-c1/application_note/gpio/spi#c1 It might be a easier way to do SPI on the C2 and fall in line with how HardKernel does it. I think between this and the networking being cleaned up it will be easier to use the C2 with Armbian. I'm actually using the C2 as a server and started using NodeMCUs for some device interfacing projects. Sometimes 4 cores and 2G RAM are overkill for simpler projects like my weather station (and NodeMCU is $3.59 delivered):

@TonyMac32 Thanks for moving this forward. I guess with software SPI it will have limited bandwidth. Odroid C1 has you load spicc module and not mess with the device tree.

@TonyMac32 OK, it uses pins 19 and 20 like Pi and C1. I used a loopback wire and ran a simple Python script: import spidev input = [1 ,2 ,3, 4, 5] print("input: %s" % input) spi = spidev.SpiDev() spi.open(0,0) output = spi.xfer2(input) print("output: %s" % output) python3 spitest.py input: [1, 2, 3, 4, 5] output: [1, 2, 3, 4, 5] So I'm confident gpio, i2c and spi are working. If your changes can be committed for the C2 Armbian build that would be most excellent. @nik-ii For UserSpace IO issues please use my github issues page otherwise it looks like everything works. I tested UserSpace IO with C2. Here's the SPI loopback in Python: python3 spiloopback.py --device /dev/spidev0.0 --maxSpeed 500000 255 128 and Java: java -Djna.nosys=true -Djava.library.path=/usr/local/lib -cp ../../jnaerator/jna-4.5.2.jar:../../jnaerator/jnaerator-runtime.jar:libperiphery.jar:demo.jar com.codeferm.demo.SpiLoopback /dev/spidev0.0 500000 FF, 80

@TonyMac32 I'll try that and see if loop back works.

@TonyMac32 The following works on the C2: gpiodetect gpiochip0 [aobus-banks] (15 lines) gpiochip1 [periphs-banks] (119 lines) sudo i2cdetect -l i2c-1 i2c DesignWare HDMI I2C adapter i2c-0 i2c Meson I2C adapter I2C adapter ./spidev_test -D /dev/spidev0.0 spi mode: 0 bits per word: 8 max speed: 500000 Hz (500 KHz) I need to figure out the MOSI and MISO pins since it's software, but it looks like all the major subsystems are cranking. It doesn't appear the C2 has pins for SPI? https://wiki.odroid.com/odroid-c2/hardware/expansion_connectors I did get SPI working on C1 here https://forum.odroid.com/viewtopic.php?f=116&t=26674

@nik-ii Take a look at https://github.com/sgjava/userspaceio/issues/2#issuecomment-427615183 I had to update the JNA lib in the Java scripts. Please follow up on github with UserSpaceIO specific issues.

@nik-ii I'm going to install on my C2 and see what's up.

@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:

@TonyMac32 So I just install the deb packages with my current release? I downloaded them and will try tomorrow.

@TonyMac32 No problem, I just got online at home.

@TonyMac32 I like option one Send me a link and I'll try tonight.

@TonyMac32 Will this be in the form of a nightly build, or do I need to build it?

@TonyMac32 I believe the C2 is software SPI. @nik-ii See Tony's reply above, but it looks like I2C and GPIO are enabled. UserSpace IO components can be used individually. In other words I can use just GPIO if it's enabled. You can try a simple flashing LED example.