Tido

yeah.
 
I'm sure, I can probably find some examples for that.  The permissions are in the build system now, so item 0 should be unneeded.

Edit: User Space IO depracated. Use Java Periphery instead https://github.com/sgjava/java-periphery
 
https://github.com/sgjava/userspaceio
 
After a lot of work and testing I have produced the User Space IO project! It provides Python 3 and Java 8 bindings for Linux user space GPIO, SPI, I2C, PWM and Serial interfaces. This allows cross SBC and cross language development using a common API. I took two best of breed C APIs for Linux user space libgpiod and c-periphery and produced CFFI bindings for Python and JNA bindings for Java. Since all the bindings closely match the C API it's easy to move from language to language. The side effect of using the Java library is that it should work with many different JVM based languages. How about creating your programs in Kotlin or Scala for instance?
 
GPIO access uses the new gpiod interface and not the deprecated sysfs interface using libgpiod v1.1 (head from git repo). GPIO, SPI, I2C and serial interfaces expose all the low level functionality. I have added some helper methods for handling repetitive functions like building I2C messages, reading words from two registers, etc. You can of course go as low level as you need to. Please use Github to post any issues, pull requests, etc. I have tested Nano Pi Duo for 32 bit and NanoPi Neo +2 for 64 bit compatibility. I'll test more SBCs as I have time. Also, I have deleted https://github.com/sgjava/libgpiod-extra since User Space IO supersedes it.
 
Based of some of the questions I had in the past please note the following:
gpiod_ctxless_event_loop_multiple can handle GPIO interrupts Miscellaneous GPIO request flags GPIOD_LINE_REQUEST_FLAG_OPEN_DRAIN, GPIOD_LINE_REQUEST_FLAG_OPEN_SOURCE, GPIOD_LINE_REQUEST_FLAG_ACTIVE_LOW Non-root access using rc.local. Demo program using hardware PWM to flash LED:
 

I cannot remember how I did it, but as I called it 'merge' I must have collected it from different sources, like sysfs & device tree. I think even Tony gave me that tipp.
Attached a LibreOffice spreadsheet with 3 sheets in it,  'merge' is the one you are looking for
GPIO Pins.ods

Every connector is a resistor, and depending on the design of this device it can become an even bigger resistor.
 
if you check the picture, the cable is AWG24, as thin as a hair.  Not worth the money in any case.
 
AWG20:
https://www.ebay.ca/itm/GENUINE-LG-G4-G3-G-G2-HIGH-SPEED-20AWG-MICRO-USB-CHARGER-LEAD-CABLE-BLACK/252502327505?

Free Electrons is changing to a new name, in the context of a trademark dispute.
 
The weird thing about this campaign - you support ALLWINNER, while ALLWINNER actually should pay Bootlin to do this for them.
Especially people using OSMC  OpenELEC  LibreELEC  Kodi - should be strong supporter of this Kickstarter ... unless you use a different SoC.
 

For GbE, I have been playing with the delays, but no, so far no setting appears to be more stable than any other, so I'm not certain it is delay-related, and performance degrades quickly as you deviate from the pre-set delays.

Sent from my Pixel using Tapatalk

Free Electrons is changing to a new name, in the context of a trademark dispute.
 
The weird thing about this campaign - you support ALLWINNER, while ALLWINNER actually should pay Bootlin to do this for them.
Especially people using OSMC  OpenELEC  LibreELEC  Kodi - should be strong supporter of this Kickstarter ... unless you use a different SoC.
 

This is far from kernel hacking or any serious involvement in electronics - it is only a serial console, 3 wires connected to board and USB to your desktop computer. This basic (debug) tool is sometimes the only way to proceed on boards without HDMI and a network. "Normal" users do accept advice and we just try to help them the best way we know.

Incredible !
As I said in many other threads, USB-TTL-Serial USB dongle  as described at http://linux-sunxi.org/UART is a MUST for anyone who plays with any SoC boards !!!
Those are afordable, usually around $0.99 on eBay, you should keep several of the in inventory if you have several SoC boards ...
 

Hi. When you install RPi monitor on a board using legacy 3.4 kernel (in my case, Orange Pi Plus2e), you can notice an error message in the "Memory" section of the web interface, as well as a very weird big number of used memory.
That is caused because it tries to read some value from /proc/meminfo (named "MemAvailable") that wasn't implemented in that version of the kernel (I think it was implemented in 3.14, if I remember well).
 
So I have made a custom version of the memory module, which gets the value for used and available memory using the same algorythm as HTOP, which has been many years around being very useful. I am attaching the file "memory_legacy.conf". In order to use it:
Copy it to /etc/rpimonitor/template/ Edit /etc/rpimonitor/data: Change: include=/etc/rpimonitor/template/memory.conf for: include=/etc/rpimonitor/template/memory_legacy.conf  
Maybe the devs could include it in the default installation, if they see fit.
memory_legacy.conf

Yes, but in a long run this may not be enough, there are too many sunxi SoCs and not that many involved developers to get mainlining efforts close to Amlogic or Rockchip levels, and any documentation issue only makes it worse, especially for essentials like DRAM code.

While they still don't cooperate with open source community as good as Rockchip, they at least are more cooperative. I asked for HDMI/DE2/DE3 documents and received all of them. Someone else asked about AC200 doc and also receive it. Or better said, they were uploaded to linux-sunxi.org. I would say that is a very good improvement.

beating a dead horse is not going to get you anywhere.
I rather support Amlogic or Rockchip

I agree with regard on the HELP, but the graphicle interface of yours is way too much - in my humble opinon.
A review of current interface sounds good, but always keep low maintenance in mind.
Days only have 24hrs

Right, why did you post to this topic while I had it open? I think I need to go check my network security now!   
 
Anyway, indeed... if this is node red and MQTT running, there is nothing to stop an ESP8266 with screen... say a 1.3" OLED or a 2.2" TFT, etc, from also polling the orange pi / etc and showing the data. 
 
 

and what does stop you of doing so ?

My opinion (regarding project aims):
- View Armbian as a base, reasonably minimal OS images. Unfortunately this doesn't work well for targeting inexperienced users, or rather when such users are attracted to the project.
- Explaining "minimal" and "reasonable" to people who don't listen is hard. People expect Kodi to work out of the box on any hardware, expect a perfect desktop performance even on OPi Zero 256MB and expect Mali drivers to magically fix all performance issues.
- Trying to add things to the base image is bad for the project if it can't be fully supported, if it can prevent making project-wide advancements. IMO a lot of things added to the image are not really required but they increase the maintenance efforts. For example for me it would be easier to make a build repository fork and clean it up than try to resolve all possible conflicts with the recently added Realtek wireless drivers (in addition to important device-specific patches) when I decide to upgrade devices that I use to mainline kernel v4.15.
- We still fail to explain what Armbian is. I see it as Ubuntu/Debian + bootloader with customizations + available kernel(s) with customizations + minimal OS (userspace) customizations and some optional tools/scripts like armbian-config. A lot of support requests are related to upstream packages, a lot of problems are related to kernel/userspace compatibility and people want optional stuff to work perfectly (if it's available in the menu it should work, why not?) while we still have base platform issues. 
- Current web pages and the direction they are changing doesn't help explaining what Armbian is and what level of support can be expected for different images and kernels, unless adding random affiliate links to Amazon should somehow help with this in the long run.
 
The problem here is that "interesting" is subjective. @tkaiser is mostly interested in NAS type boards with high performance and recent enough kernel for using btrfs. Adding ECC RAM to such board multiplies the "interestingness" of a board by 10.
Some people are interested in a generic home NAS device and don't care if its max sequential speed is 40MB/s instead of 400MB/s 100MB/s as long as it is much cheaper.
A lot of people are interested in desktop/multimedia use cases, and here ARM devices in general have a lot of problems unless you are running Android on a well supported device.
Some people bought the cheapest device they could find and expect it to do everything - NAS, desktop, multimedia player, IoT/GPIO stuff, etc.

Neat, I'll take a peek at that when I have a moment.
 
These are some other locations that seem like they may have helpful resources:
http://docs.khadas.com/social/BuildBootloaderAndRamfs/
https://forum.odroid.com/viewtopic.php?f=138&t=20869&p=180545&hilit=booting+alternate+kernels#p149212
http://www.denx.de/wiki/DULG/UBootScripts
 
Maybe tftp is the way to get that stuff loaded...
 
--Matt

I have deleted this project please see https://github.com/sgjava/userspaceio as it covers I2C, SPI and serial in addition to the new GPIOD.
 
I posted instructions over in the H2/H3 forum, but my build project for libgpiod should work on any Armbian mainline distribution, so I'm posting a link here to my Github site. The install is scripted and comes with the ability to generate Python and Java bindings. libgpiod replaces the deprecated sysfs since kernel 4.8. libgpiod-extra project aims to make cross platform/cross language GPIO development a reality. No more one off hacked up Wiring Pi or RPi.GPIO for each SBC.
 
I need help testing across multiple SBC platforms. Just follow the instructions on https://github.com/sgjava/libgpiod-extra.
 
Verified on:
NanoPi Duo (H2+) NanoPi Neo+ 2 (H5) Python:
import time from argparse import * from libgpiod.libgpiod import * parser = ArgumentParser() parser.add_argument("--chip", help="GPIO chip number (default 0 '/dev/gpiochip0')", type=int, default=0) parser.add_argument("--line", help="GPIO line number (default 203 IOG11 on NanoPi Duo)", type=int, default=203) args = parser.parse_args() consumer = sys.argv[0][:-3] chip = gpiod_chip_open_by_number(args.chip) # Verify the chip was opened if chip: line = gpiod_chip_get_line(chip, args.line) # Verify we have line if line: # This will set line for output and set initial value (LED on) if gpiod_line_request_output(line, consumer, 0) == 0: print "\nLED on" time.sleep(3) # LED off gpiod_line_set_value(line, 1) print "LED off" gpiod_line_release(line) else: print "Unable to set line %d to output" % args.line else: print "Unable to get line %d" % args.line gpiod_chip_close(chip) else: print "Unable to open chip %d" % args.chip Java:
import java.util.concurrent.TimeUnit; import libgpiod.LibgpiodLibrary; import libgpiod.LibgpiodLibrary.gpiod_chip; import libgpiod.LibgpiodLibrary.gpiod_line; public class LedTest { public static void main(String args[]) throws InterruptedException { // Default GPIO chip (NanoPi Duo chip 0) int chipNum = 0; // Default line int lineNum = 203; if (args.length > 0) { chipNum = Integer.parseInt(args[0]); lineNum = Integer.parseInt(args[1]); } // Use to debug if JNA cannot find shared library System.setProperty("jna.debug_load", "false"); System.setProperty("jna.debug_load.jna", "false"); // Use class name for consumer final String consumer = LedTest.class.getSimpleName(); // Load library LibgpiodLibrary lib = LibgpiodLibrary.INSTANCE; final gpiod_chip chip = lib.gpiod_chip_open_by_number(chipNum); // Verify the chip was opened if (chip != null) { final gpiod_line line = lib.gpiod_chip_get_line(chip, lineNum); // Verify we have line if (line != null) { // This will set line for output and set initial value (LED on) if (lib.gpiod_line_request_output(line, consumer, 0) == 0) { System.out.println("\nLED on"); TimeUnit.SECONDS.sleep(3); // LED off lib.gpiod_line_set_value(line, 1); System.out.println("LED off"); lib.gpiod_line_release(line); } else { System.out.println(String.format("Unable to set line %d to output", lineNum)); } } else { System.out.println(String.format("Unable to get line %d", lineNum)); } lib.gpiod_chip_close(chip); } else { System.out.println(String.format("Unable to open chip %d", chipNum)); } } }  

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.

OK, I got it to build finally! I'm working on a how-to and will post that once I verify the steps and that it actually works, thanks!
 

Holy smokes, I didn't think the RPi.GPIO clone would be such a pain, but the bonus is I fixed some bugs in the C code and changed how callbacks work a bit. AIOAddGPIOCallback no longer sets pin direction, so you must call AIOAddGPIO and set the pin direction to GPIO_IN. I also added AIORemoveGPIOCallback which sets edge to "none" and causes the pthread to exit. This operated more like RPi.GPIO by leaving the pin set the way it was before the callback and only changes edge. I also fixed AIORemoveGPIO yesterday as it was using the literal pin number and not the mapped pin, so the pin was left in it's previous state (i.e. /sys/class/gpio/gpio123 was still there).
 
I was able to implement most of the RPi.GPIO event methods:
add_event_detect remove_event_detect add_event_callback I still need to work on:
wait_for_edge event_detected Once this is done I should be able to test Luma.OLED on a few different model SBCs without code changes if I use the same pins. This will be the ultimate test. No more hacked up RPi.GPIO for each SBC! I had to have a custom RPi.GPIO for Odroid C1, Pine A64, the various Nano Pis, etc.

I have a few things I'd like to "babble" about along those lines, however I think it would be best termed "philosophy of application".  In this case there are a few things that may help, such as board config templates (what kernel options/etc are common as possible across all Armbian kernels/etc). 
 
 
I would say "freezing" would be preferable to "dropping".  This project provides more than enough information to recompile kernels and add modules/make small changes/etc, there's no need for any of the devs to pull out a board with a cm of dust on it and risk starting an electrical fire when they plug it in and the capacitors have dried out [dramatization for effect] simply because one guy wants 'x' feature on 'y' board that hasn't been built in 'z' years.
 
Reading over @botfap's post I agree, other than the RPi bits, like with the Tinker Board we'd constantly get the "But the Vendor OS can *insert something a *team* of professionals implemented that you weren't able to do in the 3-4 hours you put into this on an average night when nothing interferes*. Raspbian does everything you should and shouldn't do with one, a similar reality is why I haven't pushed a "community support" package for the Khadas VIM.  All Meson GX/GXL (Amlogic S905(X)) boards are very nearly identical and can be supported very easily as a family, but Khadas already has a pile of fully capable OS images, I have no desire to "compete" with them by pushing a 66% or so capable Armbian branded image.  RPi is the same sort of situation.
 
We have a lack of metrics for what constitutes "ready" or "supported".  Now, some requirements are difficult to make "hard requirements"  But this goes back to the "matrix of what works" I proposed some time ago, if the hard requirements are met, and the board's aggregate support/capability is over let's say 75%, then it could be considered (arbitrary numbers).  I won't pretend to be an impressive developer, but I am in automotive engineering, and my life revolves around gate reviews and processes.
 
 
Keep it secret, keep it safe. 
 
There are, in my mind, two questions that must be asked before supporting anything:
 
What does Armbian bring to the SBC and its users that the Vendor does/can not? This needs to be in "dumb user" terms.  A board for watching cat videos is not an Armbian device. What does the SBC, it's vendor, and its users bring to Armbian that would be a benefit to the community? Will these users contribute?  Will they donate?  Will they spread the good word? Will the vendor contribute resources and will those resources outweigh the support effort for the device? In the case of the Pi, it is a cat video watching, Scratch programming, "ZOMG I AM 1337" type of board.  I think in terms of a beginner Linux doodling machine it's fine.  But it does not have any hardware capabilities that would benefit from Armbian in real terms.  I'm sure the OMV images perform much better than if they weren't Armbian, but how much better is that when the hardware is so bad?  I'm glad OMV and tkaiser were able to squeeze some water from the performance stone that is RPi, but to go that one extra step and have a general-purpose official Armbian-branded image would be stupid I think, the answer to the "Important Questions" would be as follows:
 We can make the Citroen 2CV go 5 km/hr faster, but it is still outrun in a 1978 Diesel Rabbit towing a trailer. The users would bring us exposure (probably bad when we're not as "friendly" (OS or devs) as Raspbian) and they would undoubtedly require more resources in support than we would gain in donations/contributions to continue the work on other boards.  Botfap's situation is quite different, if funding were assured and the customer defined then support is quite different than with an "anybody can download it and complain" model of an open project like this.

Hi,
Larry patiently showed my how to use the armbianIO library to talk to the GPIO pins.
While all other go for Python and compatible to RPi - this is different.
This is designed native for SBC (Single Board Computer). No translation to the GPIO numbering necessary it fits 1-to-1.
We have built a first show case where 3 LED show you the temperature of your SoC. I guess you can imagine yourself several scenario's where this can be very helpful.
If you have some LEDs, 25min time it would be great to hear from you if it worked with your SBC
To start, please look here !
 
Cheers
Tido

Exactly. The average RPi user often has really no clue at all why he bought an SBC (and you should please stop spreading this 'charity/education' BS since 'Pi for education' reality looks different). Users choosing any of the alternatives did at least some research and thought about what they want to achieve and how. And this (the user base) is the real reason why Armbian should never start to support Raspberries since once these people start to arrive here in the forum Armbian is finally dead (but maybe the current approach to semi-support as much SBC as possible will already kill the project).