sgjava

OK, I'll try nmtui on the next Duo I configure to compare the two.

Previously I just edited /etc/network/interfaces (or added file to interfaces.d), but Ubuntu 18.04 uses Netplan now. The old way worked by editing the SD card, so you never had to login into the serial console. I'm not sure if there's a way to do this with Netplan, but this is what I did to get wifi working: Login via serial console or plug in Ethernet (I used the Duo mini shield which has Ethernet port) sudo nano cat /etc/netplan/armbian-default.yaml network: version: 2 renderer: NetworkManager wifis: wlan0: dhcp4: no addresses: [192.168.1.69/24] gateway4: 192.168.1.1 nameservers: addresses: [192.168.1.1,8.8.8.8] access-points: yourssid: password: yourpassword sudo netplan generate sudo netplan apply ip a Make sure to modify the addresses, gateway4, nameservers, access-points to fit your needs.

User Space IO uses libgpiod for GPIO stuff and is built from source. The mapping is a bit different than sysfs (the old way of doing GPIO), but pretty straight forward. Each GPIO chip starts at pin 0. It should work with any mainline kernel that supports user space mapping of GPIO, SPI, I2C, PWM and MMIO.

@Igor the Ubuntu releases (4.14 kernel currently) have been very solid on the Duo. I have one on my network running 24/7 without any issues for months. This was the nightly Debian release with the 4.16 kernel. The interface comes up for less then a minute then dies. I logged into the serial console and it shows wlan0 unavailable (haven't had time to dig in more). I'll wait for the Ubuntu with 4.16 and test again. I'm just happy I can access all the user space stuff without sudo now that PWM works.

I just tested this with Linux NanoPi-Duo 4.16.0-rc6 #239 SMP Wed Apr 11 14:03:49 CST 2018 armv7l armv7l armv7l GNU/Linux using official FriendlyArm image. Just add gpio group, add your non-root user to group and add udev rules /etc/udev/rules.d/99-com.rules I posted above. I tried the Armbian nightly image with 4.16 kernel, but wifi kept dying.

OK, thanks. I'll wait for 4.16.

SUBSYSTEM=="pwm*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/pwm && chmod -R 770 /sys/class/pwm;\ chown -R root:gpio /sys/devices/platform/soc/*.pwm/pwm/pwmchip* && chmod -R 770 /sys/devices/platform/soc/*.pwm/pwm/pwmchip*\ '" This seems to set the permissions correctly, but nothing happened (at least no errors) while sudo works fine. I'm using kernel 4.14.18 and it looks like it was merged into the RPi kernel http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-December/007193.html

Nice, I did that before I asked. See https://github.com/raspberrypi/linux/issues/1983

I've been able to use all the other user space I/O without being root. PWM on the other hand seems to create files only after opening device. Is there a udev rule that will work with 4.14 kernel? For all other devices I use a simple rc.local script: chown -R root:gpio /dev/gpiochip0 chmod -R ug+rw /dev/gpiochip0 chown -R root:gpio /dev/gpiochip1 chmod -R ug+rw /dev/gpiochip1 chown -R root:i2c /dev/i2c-0 chmod -R ug+rw /dev/i2c-0 chown -R root:spi /dev/spidev1.0 chmod -R ug+rw /dev/spidev1.0

@chwe I just did a quick test using User Space IO which uses liggpiod 1.1. On a NanoPi Duo I was able to toggle a pin at 25 KHz (on/off cycle) with Python. If you need speed or precision I'd go with hardware PWM which User Space IO supports.

If you want to get ahead of the curve a little I've been testing libgpiod master with User Space IO. This version includes Python bindings, so I'm no longer generating CFFI bindings for this library. I've converted all the example code to use the new bindings. User Space IO is Python 3 and Java 8 bindings for Linux user space GPIO, SPI, I2C, PWM and Serial interfaces. User Space IO is a consistent API for C, Python 3 and most JVM languages. No more hacked up RPi.GPIO and WiringPi for each SBC model.

@chwe actually 0 for on and 1 for off is correct. I'm wiring my LED like https://www.sunfounder.com/learn/Super_Kit_V3_0_for_Raspberry_Pi/lesson-1-blinking-led-super-kit-v3-0-for-raspberry-pi.html. This works the same on my NodeMCU as well (ESP8266).

@chwe I don't remember why I removed this. I just added it back. Try again and it should register with Python now.

As a dev I vote to keep the dev packages in. Sure is nice to have the build tools (even git client) installed even if things like libtool and pkg-config are missing from the base. If you are going for a minimal install I understand stripping all this stuff out, but I'm not sure how important it is to have a 700K vs 1.6 G image in today's terms. As @tkaiser points out most people have moved on beyond 4G SD cards. I've been using 32G for years and the price/performance is good for what I need it for. I've have some home made security cameras that write/read/delete 100s of movies and images a day 24/7 for years without failure. I realize there may be more intensive usages scenarios (more write intensive), but at the current pricing levels I'll toss the SD out every few years if I have to. As with all things the lowest common denominator or race to the bottom isn't always the best strategy. Stability and standardization are more important to me then a little extra RAM, a little more SD life, etc. Not that these are not important, but the bigger picture I think is more important to focus on.

I agree, and maybe just use a sizeof since the arrays are static. Then there's no need for an array of number of pins.