sgjava

Thanks man, trying to get use out of these old boards! I also noticed Odroid C1 (same focal image) was segmentation faulting. Looks like that got cleaned up with Armbian_20.05.0-trunk.148_Odroidc1_focal_legacy_5.4.43.img. SD performance was really bad, so trying new SD with it, although that's nothing new with C1.

Tested Armbian_20.05.0-rc.149_Nanopim1_focal_current_5.4.43.img and I even tried hooking up video to see what was going on and nothing. Image doesn't expand on SD. I know this isn't supported, but would be nice to have focal on my old M1s. Also, I've tried the 5/24 image and the same issue.

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

Looks like ARMV8 64 bit is good as well, so I can proceed to finishing up the GPIO wrapper methods.

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.

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.

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.

I've installed a wireless alarm system, but I want to use all my old wired stuff from my original alarm system. I started down the road of using an ESP8266, but GPIO.INT was flaky and GPIO pins limited, so I ordered a MCP23017 and figured Why not just do everything with one NanoPi Duo? I have a few of them and they are made for breadboard prototyping. Plus with the built in Ethernet I can have wired primary and wireless backup networking. I even rolled my own Ethernet adapter since the breakout adapters cost $5+. If you have already done this and have any wisdom to share I'd like to hear it. No turning back now!

UART1 is specified in this diagram. Enable it in armbian-config, install userspaceio and look at https://github.com/sgjava/userspaceio/blob/master/c-periphery/python/src/serialtest.py

@martinayotte There were rc, but no 5.5.0-sunxi until I pulled down latest duo distro. Could have sneaked up on me

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

So 5.5.0 finally showed up in dev on 1/25. uname -a Linux nanopiduo 5.5.0-sunxi #trunk.034 SMP Mon Feb 3 08:38:40 CET 2020 armv7l armv7l armv7l GNU/Linux Saves me from building kernel. libgpiod master now builds for me!

OK, that's good to know.

I noticed that on the Duo I can select 5.5.0-rc6-sunxi in dev. Is there any idea when 5.5.0 will be the default release? Also, I noticed that there's no matching 5.5.x kernel source. I'm playing with linux-headers-dev-sunxi to see if I can compile libgpiod master which requires 5.5.0.

@fourtyseven I agree and shift registers and multiplexers will solve the limited GPIO pins issue, but my thought is if I have to go that route and add a lot more software complexity then I'll go the NodeMcu route (all GPIO pins can be hardware PWM too instead of one pin). The Duo is very limited GPIO wise. This is the Frankenboard I test User Space IO on. GPIO, I2C, SPI, PWM, LED, etc. are all used.

@fourtyseven Or just use a NodeMcu since it has a lot of GPIO pins. I often replace a SBC with a NodeMcu and some Lua code for less complex tasks. It makes an excellent micro controller as well. And at $3 each you cannot beat the price.

@fourtyseven I'd probably use hardware PWM for that, but I hear what you are saying.

@fourtyseven Yeah with interrupts and other OS overhead it seems unbelievable. Plus I'm not switching to golang to attain this speed or pick a particular board. 80 MHz is a corner case that most devs will never need. Even 80 KHz is overkill for most needs except bit banging possibly.

@fourtyseven I threw together a non-scientific libgpiod read/write test and the results are 71 KHz write and 85 KHz read on a H2+ (Duo). Maybe not good enough to simulate a protocol, but plenty good for lots of other things. For the most part I'll take the slowness over lack of portability. https://periph.io/ claims 80 MHz, but I installed it on the Duo and it only detects sysfs stuff, thus it will be slower than libgpiod. There's really no way I found to stay portable and get register level performance.

@Tido Just get a list of system LEDs and do what you wish: cd /sys/class/leds ls -1F

@Tido It's an API for system LEDs. https://fabiobaltieri.com/2011/09/21/linux-led-subsystem An example in User Space IO https://github.com/sgjava/userspaceio/blob/master/c-periphery/python/src/sysled.py

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

@fourtyseven slow is relative Precision timing might be best left to a dedicated micro controller. I know ligpiod has less of a chance of losing an event than sysfs, plus events are timestamped. Check out for more details

Here's my working rc.local (usio is the group I want to give access to): chown -R root:usio /sys/devices/platform/leds/leds chmod -R ug+rw /sys/devices/platform/leds/leds

@fourtyseven I haven't really had time for this, but if you understand the underlying frameworks used it should be easy to determine relative performance. Let's look at GPIO for instance. There are basically three modes (fastest to slowest): Board-specific Linux drivers that access GPIO addresses in /dev/mem for fasted performance at the trade-off of being able to run on very specific versions of single-board-computers. In the future, the board-specific Linux drivers may be removed in favor of only supporting libgpiod and sysfs Linux interfaces. libgpiod for fast full-featured GPIO access on all Linux distros since version 4.8 of the Linux kernel. Slower and limited-functionality GPIO access via the deprecated Sysfs interface (/sys/class/gpio) when running on older Linux distro versions with a Linux kernel older than version 4.8. I've never had to go the /dev/mem route and would only do that as a last resort. Remember the idea behind User Space IO is cross SBC/language support. Now let's talk about the wrappers. Obviously Python wrappers are going to be faster than the JNA wrappers generated for the JDK. Again, the trade off here is I can use a similar API to C and Python in Java and other JDK languages. Others have done benchmarks https://blog.adafruit.com/2018/11/26/sysfs-is-dead-long-live-libgpiod-libgpiod-for-linux-circuitpython "So we’re pretty psyched about libgpiod. From our experiments, its much much faster than sysfs. Its not as fast as mem twiddling, but that’s not too surprising, there’s still kernel messages and error checking done. A Pi 3 got us 400Khz pin output toggles in a loop in C, 100KHz in Python examples, and that’s pretty good for bitbanging."