sgjava

This has been replaced by: User Space IO get more details on this thread.
 

 
Well, it's time to say goodbye to sysfs and hello to libgpiod! @zador.blood.stained pointed me in the right direction, but you need to do one little hack I'll explain below involving compiler_types.h. I tested this on a NanoPi Duo, but it should work on any mainline Armbian release (and other distros as well) as long as the kernel is >= 4.8. Try ls /dev/gpiochip* and see if anything is listed. If so, then proceed.
 
I'm continuing work on my Github site https://github.com/sgjava/libgpiod-extra, so please report any issues there. There is an Armbian install script that automates the steps below I generated the Python wrapper, but there's a lot of functions to test, so I'm not sure of the quality. I'm working on some simple Python tests.
sudo armbian-config, Software, Headers sudo apt-get install libtool pkg-config git clone https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git cd libgpiod mkdir -p include/linux cp /usr/src/linux-headers-$(uname -r)/include/linux/compiler_types.h include/linux/. ./autogen.sh --enable-tools=yes --prefix=/usr/local CFLAGS="-I/usr/src/linux-headers-$(uname -r)/include/uapi -Iinclude" make sudo make install sudo ldconfig Let's try some commands:
 
sudo gpiodetect
 
gpiochip0 [1c20800.pinctrl] (224 lines)
gpiochip1 [1f02c00.pinctrl] (32 lines)
 
sudo gpioinfo | grep "\[used\]"
 
    line  10:      unnamed "nanopi:blue:status" output active-high [used]
    line 166:      unnamed         "cd"   input  active-high [used]
    line 202:      unnamed  "interrupt"   input  active-high [used]
    line 205:      unnamed      "reset"  output   active-low [used]
    line   6:      unnamed          "?"  output  active-high [used]
    line   7:      unnamed   "vcc-wifi"  output  active-high [used]
    line  10:      unnamed "nanopi:green:pwr" output active-high [used]
 
Notice how it found the Duo's built in LEDs
 
Now let's test the Duo's built in button (press and release 3 times):
 
sudo gpiomon --num-events=3 --rising-edge gpiochip1 3
 
event:  RISING EDGE offset: 3 timestamp: [1516774143.944174870]
event:  RISING EDGE offset: 3 timestamp: [1516774145.123474395]
event:  RISING EDGE offset: 3 timestamp: [1516774145.987531088]
 
Wire up LED (the normal way) and use Duo's IOG11 then to turn on and off:
 
sudo gpioset gpiochip0 203=0
sudo gpioset gpiochip0 203=1
 
Python code
import time from libgpiod.libgpiod import * chip = gpiod_chip_open("/dev/gpiochip0") line = gpiod_chip_get_line(chip, 203) # The will set line for output and set initial value (LED on) if gpiod_line_request_output(line, "test", 0) == 0: time.sleep(3) # LED off gpiod_line_set_value(line, 1) gpiod_line_release(line) gpiod_chip_close(chip) More reading at https://www.cnx-software.com/2017/11/03/learn-more-about-linuxs-new-gpio-user-space-subsystem-libgpiod and https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/README. Maybe @Larry Bank will work on ArmbianIO II It looks like in the old Github site there was a milestone to create Python and C++ wrappers https://github.com/brgl/libgpiod/milestone/3. Once I learn more about libgpiod I may just generate them like I did for ArmbianIO.

The Luma library allows you to display text, graphics, animation, etc. on multiple display types. Here I will describe the easiest one to configure which is Luma.OLED and the I2C version of the SSD1306. You can find these displays on EBay and Amazon for less than $10 US each (you can get them for less than $3 US if you order from China, but it might not show up). I've configured Luma on many SBCs and it's my go to library if I need a small display for projects.
 

 
Requirements
NanoPi Duo (I used V1.0 board with 512 MB RAM) flashed with Armbian image. This will work with or without the mini shield. Small nylon nuts, bolts and standoffs if you want to mount display I2C OLED display (check http://luma-oled.readthedocs.io/en/latest/hardware.html) 4 female to female jumper wires If you want to configure wifi the easy way just edit the following file on the SD sudo nano /media/username/43296f0d-fc9e-4cec-b3bf-f335fc72f371/etc/network/interfaces and add:
allow-hotplug wlan0 iface wlan0 inet static address 192.168.1.69 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.1 wpa-ssid your_ssid wpa-psk your_password Comment out the eth0 stuff. You can do it the hard way with the debug serial interface though if you want When I ordered my Duos I forgot to order the USB dongle, so I would have been out of luck otherwise. Boot up and configure the Duo the way you like, power off and wire up the display as follows:
VCC to either 5Vin or 3V3 GND to GND SCL to SCL SDA to SDA Power up Duo and configure I2C:
sudo nano /boot/armbianEnv.txt and add i2c0 to overlays= sudo apt-get install i2c-tools sudo usermod -a -G i2c username (non-root user you created) sudo i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- If you see the 3c on i2c0 then you are in business. Let's install Luma.OLED:
sudo apt-get install python-dev python-pip libfreetype6-dev libjpeg-dev sudo -H pip install --upgrade pip sudo apt-get purge python-pip sudo -H pip install --upgrade pip setuptools sudo -H pip install --upgrade luma.oled sudo -H pip uninstall RPi.GPIO (this will not work on Duo and is not needed for I2C) OK, let's create a simple demo program to make sure things are working nano i2chello.py:
import time from luma.core.interface.serial import i2c from luma.core.render import canvas from luma.oled.device import ssd1306 serial = i2c(port=0, address=0x3C) device = ssd1306(serial) with canvas(device) as draw: draw.rectangle(device.bounding_box, outline="white") draw.text((3, 3), "Hello", fill="white") time.sleep(10) And you should see (screen shot from the Luma emulator):
 

 
Now we can install the Luma examples:
sudo apt-get install git-core libsdl-dev libportmidi-dev libsdl-ttf2.0-dev libsdl-mixer1.2-dev libsdl-image1.2-dev
git clone https://github.com/rm-hull/luma.examples.git
cd luma.examples
sudo -H pip install -e .
Let's run an example: sudo python examples/invaders.py -d ssd1306 --i2c-port 0 --i2c-address 0x3c

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.
 

@Tim Makarios Yeah, I suspect there's going to be consistency issues depending on the distro and board. I'll go ahead and add the build stuff since it wont hurt if it's already there.

@Tim Makariosall set. I added BRANCH for the linux headers. I also fixed the prompt for /etc/issues asked during apt upgrade.

Good catch, I need to get the release as well. I'll fix that tomorrow. For now you can use the manual steps and "current".

I figured it out. I had it wired to MI instead of MO! I'll do a write up once I have everything working the way I want.

I can use 
echo 0 >/sys/class/leds/status/brightness  
to turn off the status led (blinking blue one, but I was to turn off the bright ass green one. I assume this is mmc1::, but I cannot turn it off.

@KeeratiI replied to your post on github. The input file is for MMIO GPIO mappings and not used by LedBlink. Use --help argument on any demo or tool for list of arguments such as gpio chip, pin, etc.

Java UIO provides high performance Java interfaces for Linux Userspace IO. Java UIO was built from the ground up to use modern kernel APIs, libraries and code generation techniques to provide a best of breed cross platform approach. It does not make sense to recreate the wheel like so many other IO libraries. JDK 17 LTS is supported out of the box.
 
I've been committing code to U8g2 that utilizes the same userspace code at the C level and dramatically improved the performance of HW/SW SPI and I2C in the arm-linux port. I also made the arm-linux port thread safe and multi display capable (you can use this in C as well obviously). It made sense to add modularization to the Java Periphery IO library since I can take advantage of the same code generation techniques. I will continue to wrap optimized C libraries moving forward in the same modular fashion.
 
So now you can develop against IO and small displays with one code base in Java.
 

@lanefuI love the device tree (the one with the boards welded on). I ended up using a storage box with little drawers I got off Amazon and made the cut outs with a rotary tool. This was right after I had it complete. Those Android sticks were quad cores running Linux. That's how I started before most SBCs were sold. Note the active cooling
 

OK, so no answers  Well as usual I pressed on. My first mistake was using JNA generation (but it was easy), so I researched JNI. Well JNI is very cumbersome to do by hand, so I looked for a JNI code generator and found one call HawtJNI. Of course it wouldn't work with Java 11 which is the Java LTS version, so I created a fork. Use the JDK11 branch if you want to play with it because I don't know if the PR will be accepted. I started wrapping c-periphery since it now supports the new /dev/gpiochip way of accessing the GPIO chips. I ran a performance test (I validated on a scope) and I'm getting ~235 KHz on a v1 Nano Pi Duo! That's over 500K writes per second compared to 2K using JNA and libgpiod. Even python-periphery yields ~37 KHz which is a pure Python version.
 
Any ways exciting news for bit bangers of the world or anyone needing high performance GPIO. Once I have the GPIO code working I'll post on my Github site and announce. Since Bulldog only supports three boards this is good news for Armbian folks with a wider array of supported boards. I still need to test ARMv8 64 bit.

I'll report back once I see the issue resolved. I think a couple days was the maximum time without losing the NICs.

OK, so I have things dialed in a bit better now. FFMPEG seems to like TCP over UDP for these streams. I'm seeing a lot less artifacts in the videos. Below is 12 hours of network and CPU activity for 3 4K cams at 12.5 FPS and 1 4K cam at 15 FPS (four 4K cams total) at highest quality. CPU seems to max out around 10% per camera and network maxes out around 45 mb total. I'm using a 1G PoE switch, so the bandwidth will never be an issue. The question then becomes how much more real-time processing can I do. CV routines are typically expensive even though I've learned tricks using ROI (region of interest). This isn't as much of a problem with a single camera, but I'm planning on six cameras. Obviously the most important thing for me now is to capture motion videos.
 
Once the bread and butter stuff is done then I can look at adding various detection code (besides motion). The question becomes do I want real-time detection or perhaps offload that to another SBC. The fact that I can record this many 4K cameras with an Odroid XU4 is pretty amazing. Look at Blue Iris requirements https://ipcamtalk.com/wiki/choosing-hardware-for-blue-iris/ and this really doesn't cover electrical costs and heat dissipation. I'm working on a Pine 64 today with USB cam, so I'll test single camera encoding. Basically the code will scale to many cameras or a single camera.


 

OK, so I have things dialed in a bit better now. FFMPEG seems to like TCP over UDP for these streams. I'm seeing a lot less artifacts in the videos. Below is 12 hours of network and CPU activity for 3 4K cams at 12.5 FPS and 1 4K cam at 15 FPS (four 4K cams total) at highest quality. CPU seems to max out around 10% per camera and network maxes out around 45 mb total. I'm using a 1G PoE switch, so the bandwidth will never be an issue. The question then becomes how much more real-time processing can I do. CV routines are typically expensive even though I've learned tricks using ROI (region of interest). This isn't as much of a problem with a single camera, but I'm planning on six cameras. Obviously the most important thing for me now is to capture motion videos.
 
Once the bread and butter stuff is done then I can look at adding various detection code (besides motion). The question becomes do I want real-time detection or perhaps offload that to another SBC. The fact that I can record this many 4K cameras with an Odroid XU4 is pretty amazing. Look at Blue Iris requirements https://ipcamtalk.com/wiki/choosing-hardware-for-blue-iris/ and this really doesn't cover electrical costs and heat dissipation. I'm working on a Pine 64 today with USB cam, so I'll test single camera encoding. Basically the code will scale to many cameras or a single camera.


 

So I have two 4K @ 12 FPS cameras that stream to a buffer file. Currently I'm only doing motion detection, but that drives everything else obviously detection wise. On an Odroid XU4 each camera uses only 10%. Motion videos are just copied from the buffer file. I'm using H265+ without any transcoding. So far so good. Not quite ready to post up to github yet though. I doubt you get better CPU utilization than this. I'm using the substream at 4 FPS 640x480 for motion detection.

One other thing to note is I proxy mjpeg and h265+ streams, so for cameras that only allow one stream you can have security software running and still stream live. I'm using PoE cameras and will have six 4K cameras running soon. So in essence you can build a cheap NVR without the hardware requirements of Blue Iris etal or just build a single smart camera. Armbian allows hardware encoding with ffmpeg on some models, so you can even encode USB cams with low overhead.

So if you look at the device tree you'll see pin controllers like GPA0, GPA1, etc. I'm not sure how the kernel gpio device enumerates them, but basically a chip is a pin controller and lines are the pins. The main thing is soon you'll be able to look at a pin map and know exactly which physical pin it is.
 
Also gpioinfo seems to sort by chip string instead of int, thus 2, 21, 22, etc. are all 2s

OK, so while documenting the Armbian patch process I needed something actual to patch. I added gpio-line-names to the device tree, so now all lines are defined. Once I finish the documentation I'll PR this patch. No more guessing what physical pin is! At some point it might make sense to put in jumper and physical pin #.
 
 
 

I was able to build the property file for the NanoPi M1 in about 20 minutes, so now basically you can do ~2 MHz GPIO square wave on all Allwinner and S905 CPUs (you listening @TonyMac32?) without any special code or adapters. All other libraries require one off code to support GPIO register access thus they only support limited boards. In my mind this is the holy grail for cross platform GPIO performance. I plan on going through some more diverse boards, but I'm happy with the results so far. Since only one core is utilized you'll average 25% CPU utilization on quad core systems. That may be another goal using two threads to improve performance further. I have currently mapped Nano Pi Duo, Nano Pi M1,  Nano Pi Neo Plus2 and Odroid C2.
 
Check out Java Periphery for more information.
 
Another thing to consider is that you can utilize the property files in other languages as well since there's Periphery APIs for C, Python and Lua as well.
 
 

@IgorArmbian_20.11.0-trunk.41_Odroidc2_focal_current_5.9.10.img did the trick. No hangs or death after apt upgrade and reboot!

@IgorArmbian_20.11.0-trunk.41_Odroidc2_focal_current_5.9.10.img did the trick. No hangs or death after apt upgrade and reboot!

So my whole goal with java-periphery was to create a decent cross platform userspace IO library which I believe I have achieved. One of my other goals was to create a high performance GPIO API that's also cross platform. If you look around there aren't any from what I can tell. Most high performance GPIO libraries support only a few boards. What I've done is use a well known interface (GPIO device) and some MMIO code to detect deltas and generate the required resisters and masks from an input file. This surely beats doing this by hand which I tried at first. The result is code that supports Allwinner H2+/H3 and H5/H6 by using just an input file. I'm going to look at other CPU types next, but this is promising. For more info check out High performance GPIO using MMIO.

So my whole goal with java-periphery was to create a decent cross platform userspace IO library which I believe I have achieved. One of my other goals was to create a high performance GPIO API that's also cross platform. If you look around there aren't any from what I can tell. Most high performance GPIO libraries support only a few boards. What I've done is use a well known interface (GPIO device) and some MMIO code to detect deltas and generate the required resisters and masks from an input file. This surely beats doing this by hand which I tried at first. The result is code that supports Allwinner H2+/H3 and H5/H6 by using just an input file. I'm going to look at other CPU types next, but this is promising. For more info check out High performance GPIO using MMIO.

So I'm working on a generic way to do MMIO GPIO on Armbian and chatting with @diozeroit seems like a wiringPi implementation is a good place to start for ideas.  Armbian supports many FriendlyArm boards, so I took a look at https://github.com/friendlyarm/WiringNP. Of course out of the box it fails because it's probing for things found only in its home made OS distros. I found a way to hack the getBoardType function to hard code your board type for Armbian and probably other distros. This will work only on the board you hack it for. Honestly there should have been a way to pass in a parameter to override the detection code. In any event here's the method to use.
 
Look up your board in BoardHardwareInfo in my case it's a NanoPi Duo, so I'd use this. Since arrays are zero based it falls on element 32. Now I hack getBoardType and right after that line add:
*retBoardInfo = &gAllBoardHardwareInfo[32]; return gAllBoardHardwareInfo[32].boardTypeId; Then follow normal build instructions here.
gpio readall +-----+-----+----------+------+---+-NanoPi-Duo--+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | | | MIC_N | | | 1 || 2 | | | EPhySPD | | | | | | MIC_P | | | 3 || 4 | | | EPhyLinK | | | | | | LineOutR | | | 5 || 6 | | | EPhyTXP | | | | | | LineOutL | | | 7 || 8 | | | EPhyTXN | | | | | | CVBS | | | 9 || 10 | | | EPhyRXP | | | | 198 | 8 | GPIOG6 | ALT5 | 0 | 11 || 12 | | | EPhyRXN | | | | 199 | 9 | GPIOG7 | ALT5 | 0 | 13 || 14 | | | USB-DP2 | | | | 15 | 7 | GPIOA15 | ALT5 | 0 | 15 || 16 | | | USB-DM2 | | | | 16 | 0 | GPIOA16 | ALT5 | 0 | 17 || 18 | | | USB-DP3 | | | | 14 | 2 | GPIOA14 | ALT5 | 0 | 19 || 20 | | | USB-DM3 | | | | 13 | 3 | GPIOA13 | ALT5 | 0 | 21 || 22 | 0 | OFF | GPIOG11 | 16 | 203 | | 12 | 12 | GPIOA12 | ALT5 | 0 | 23 || 24 | 0 | IN | GPIOL11 | 18 | -1 | | 11 | 13 | GPIOA11 | ALT5 | 0 | 25 || 26 | | | 0v | | | | | | 0v | | | 27 || 28 | | | 3.3v | | | | 4 | 14 | GPIOA4 | ALT5 | 0 | 29 || 30 | | | 5v | | | | 5 | 15 | GPIOA5 | ALT4 | 0 | 31 || 32 | | | 5v | | | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+-NanoPi-Duo--+------+----------+-----+-----+ If you search there were other solutions by using /etc/sys_info, but I was too lazy to create that file.

@Tido I made an edit to top of post. https://github.com/sgjava/java-periphery