sgjava

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.