sgjava

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.

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.