gnasch

you can run proprietary code under linux.
for details see here:
 
http://www.datamation.com/osrc/article.php/12068_3801396_3/Bruce-Perens-Combining-GPL-and-Proprietary-Software.htm
 
http://www.barrgroup.com/Embedded-Systems/How-To/Embedded-Linux-GPL-License
 
and the definitive guide:
https://www.softwarefreedom.org/resources/2008/compliance-guide.html
 
So all the onus of developing and maintaining your code is on you.
Nobody will be able to make your product better.
It will be difficult to interface and integrate.
It will have limited success in its niche.
Then it will die.
 
Or you could open source it.,,,

The node is in sync now so it took 12 days. 

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.

I'm familiar with the armbian-config tool and while I think its cool, it may not be the best thing for the beginner. The hardest part of beginning anything is not knowing what you don't know. I've begun writing a simple tool using curses and python which hopefully disambiguates some of the features of each board. I'm currently focusing on H3 boards, since thats what I have and I'm most familiar with them.  Currently I have the ascii art and setup for the Orangepi PC, One, Zero, and Nanopi Neo. 
 
The idea is to use the arrow keys to navigate, spacebar to select, 'b' for back, and (most importantly) 'h' for help. The help menu should have enough information to get a beginner going. 
 
I'm currently working on the USB OTG section, and I'm trying to get all the configfs information on the internet into one place.  Having the option to have any amount of USB OTG gadgets selected is really cool, and I'm not sure a lot people know about it. I'm hoping to make the configuration easy, like selecting radio buttons.
 
If anyone thinks this is cool (or that it sucks), let me know. Its still in development.
Here is a gif of it in action:
 


 
You can find the (in-progress) repo here: https://github.com/MitchRatquest/armbian-helper

OK, I started on the RPi.GPIO wrapper https://github.com/bitbank2/ArmbianIO/blob/master/python/RPi/GPIO.py which basically supports reading and writing to the pins. None of the event stuff is coded yet, but you can see where I'm going. No pin mappings yet. Just keeping it the way ArmbianIO does it for now. The Led test works
import time import RPi.GPIO as GPIO GPIO.setmode(GPIO.BOARD) GPIO.setwarnings(False) # Pin 12 set to output GPIO.setup(12,GPIO.OUT) # LED on GPIO.output(12,GPIO.LOW) time.sleep(3) # LED off GPIO.output(12,GPIO.HIGH) GPIO.cleanup()  

Dear TangerineToupée:
 
I wrote a device tree user custom overlay to enable gpio-poweroff function on pin PA13 (hwd Pin8), see atatched file. The custom overlay was tested on orange Pi plus 2e, but it must work on all allwinner H3 based boards running mainline kernel 4.1x
 
I’m using armbian distro nigthly (kernel 4.14) as it won’t work on legacy kernel 3.x, so, I applied the custom overlay following the instructions on this link: https://docs.armbian.com/Hardware_Allwinner_overlays/#using-custom-overlays
 
The only problem is that the user cannot use the uart3 at the same time (hwd pins 6 and 8), but that is not a problem because H3 has 2 more uarts on the 40 pins headers that can be activated at any time.
 
regards,
 
MFM
gpio-poweroff.dts

Hi, no experience with this here, but did you read:
 
The note about overlayroot?
 
best, gnasch

Wanted to automate payroll. Needed to be as simple/easy on the eyes as possible for your run of the mill user.

General functionality is that it makes digital timecards for every employee action/swipe of an RFID tag. Every swipe also punches a Google Sheet based on company department, by utilizing regex to find column associated with employee name, then the row based on today's date. It then punches current military time to corresponding clock in/out offset. The timecard math is all done using the Google spreadsheet functions to discern overtime, total hours, etc... More will be included later to automate even the spreadsheet template even though copy/pasting once every 15 days is trivial.

It's comprised of a OPi-Zero, MFRC522 RFID Module (for employee badges) a modified case, multi LED for clock in/out prompting, Google Sheet API and several existing dependencies/repos on GitHub. The most important 'juicy', details are documented on GitHub which will get you installed and running with the API, Module, LED, etc.... With more details to come, including step by step instructions on setting up Google Sheet API, etc.... Let me know what the community thinks.

https://github.com/BiTinerary/TimeClockPi

Installation >> Connect MFRC522 Module and run >> git clone https://github.com/BiTinerary/TimeClockPi && bash ./TimeClockPi/requirements.sh

Nope, they sort it by popularity or whatever (Pine64 at the top and ROCK64 at the bottom for example) and try to group by board names (eg. putting LeMaker's Banana Pro and SinoVoip's BPi M2+ in one section while both are totally incompatible -- same problem also with NanoPis). Doing so is HIGHLY MISLEADING since not brands are important but the technical base. A NanoPi NEO 2 and a NanoPi M3 are from two different worlds while a NEO 2 and an Orange Pi Zero Plus are almost the same (especially when Armbian is running on them it will be very hard to spot any difference in usage and performance!)
 
If people search on the download page they search for features. If they're absolutely clueless we can't help them anyway. If we want to guide people a little bit we have to stop what we're doing now (focused on technical details) and start to get into the heads of our users (what are they interested in? And are these the correct reasons? Again 'SATA': Not the existence of a small port with 7 pins to connect a SATA cable to is relevant but what users associate with this. And on boards we list as what they consider the label for 'fast storage' they get just insanely slow and broken GL830 USB-SATA crap).
 
Seriously: people looking for the NAS use case click on GbE, click on SATA, check the boards, think 'the more DRAM the better', think 'the more CPU cores the better', weigh some features and end up buying an Orange Pi Plus 2 instead of an ODROID-XU4 (which is magnitudes faster as NAS but is not even considered since users think 'SATA is better than USB3'). What we do here is highly misleading and must stop.

I just got the first version ready. It should work correctly with Orange Pi Zero, OPZ+2, Orange Pi One/lite and Nano Pi Duo boards. Please let me know if you want to try it and I'll add you as a developer to my gitlab repo. Once it's in good shape, I'll share it to everyone on github.

Update:
 
I'm happy to report that my tinkerboard and northpada power supply - are still alive and in one piece (including the cables/connectors, yes I checked) - after being continually under load for almost three days. The board (under a GPIO connected fan) and psu got warm, but not hot to touch at any point, the microusb connection on the board, never once got warm.
 
BUT:
 
@tkaiser is right - even if the manner he goes about it is less than tactful - the board should be powered by GPIO. But in my case, headless usage with only a few devices connected, I don't foresee any issues. So if you plan on powering by the microusb connector (which isn't recommended  ) it should be okay with a decent PSU, well in my case it is, but YMMV.

Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB).
Basics:
It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)!

The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1).

Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm)
Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability.
How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2.

Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1).

Illustration 1: AWG print on cable
Example:
If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes?
*this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability.
 
Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2).

Figure 2: Voltage drop of a copper cable at various thiknesses
If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done.
 
Case Study:
Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2).

Illustration 2: Setup vor measurement
FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1.
Table 1: Specification of the tested chargers

Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC!
Table 2: Tested micro USB cables

Results:
After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3.

Figure 3: Voltage drop at delivered current of all chargers
Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger.  If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC.
All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4)

Figure 4: Voltage without load, with load and on output and @powerbank
.
Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side.  The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it.
Conclusion:
What's next? Should we never buy again a micro USB powered SBC?  IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load.  Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you!

Illustration 3: Recommended powersource
 
 

OK to round it up........ ( trying to wave with a white flag and wearing a blue helmet.....)
 
What I would do with a Zero is. Forget about the driver/wifi/wlan0. What do you expect for $6.99?
 
Run to the nearest Action Supermarket ( or US equivalent) and buy a cheap usb WIFI dongle. I bought one for 3 euro's. Works fine.
This one:
http://domoticx.com/usb-stick-wifi-ralink-technology-rt5370-adapter/
 
[ 4.208943] usb 3-1: new high-speed USB device number 2 using ehci-platform [ 4.418224] usb 3-1: New USB device found, idVendor=148f, idProduct=5370 [ 4.418234] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4.418240] usb 3-1: Product: 802.11 n WLAN [ 4.418245] usb 3-1: Manufacturer: Ralink [ 4.418250] usb 3-1: SerialNumber: 1.0 [ 8.589015] usb 3-1: reset high-speed USB device number 2 using ehci-platform [ 8.832680] usbcore: registered new interface driver rt2800usb Do a little udev magic magic and make a new rule
 
vi /etc/udev/rules.d/75-persistent-net.rules contains:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:13:ef:c5:2d:40", NAME="wlan0 And use nmtui to activate.. Of you go.... and forget about the driver.......
 
 
[  198.551193] wlan0: associated [  198.551371] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready  
 

 

Hi sniffyjaay
 
i have several opipcplus working in a "lean desktop" mode. They run armbian 5.25 jessie with the legacy kernel. I have tried to cut back on the insane writing of cache and state data by firefox, have installed qpdfview, the complete libreoffice, xfce4-power-manager and lightdm instead of nodm.
They are always on and run reliably over ethernet or wlan connected by the user's mount to a samba server with the data.
As surfing station and Office PC they run reasonably fast, especially when you consider that you don't have to wait for endless windows starts and -updates. When a user is logged in but not active, the OpiPcPlus falls asleep after selected half hour, and stays ready consuming only a few mA until the button is pressed, then it is back within a second. I did not bother with cases, but mounted the pi's vertically with 5mm distance on a little wood plate fixed to the desk. This plate also holds the wifi antenna on its top. The natural airflow before and behind the board is easily sufficient for cooling with a simple Al heat-spreader.
 
Until now I failed to have them fall asleep when unused without user login, although I edited logind.conf.
I would like to achieve this not only to save the little energy, but also to save writing to the SD card and to stop burning an image into the monitor.
 
hth,
gnasch
 
 

Hi Guys,
 
I have recently been contracted to a new project where I have moved out of my comfort zone (embedded 8-bit/32-bit uC) and have started my work on a H3 based device (currently NanoPi Neo) with Armbian.
Over the course of my work I have managed to get up to speed with the basics; configuration, scripting, hardware and interfaces and device trees to a point where I can now work on the device as a proof of concept.
The work that has been contributed so-far to the armbian project is impressive as is the active and knowledgeable forum - to which I hope I can contribute.
 
One element which I cannot find an easy solution to is one of remote update. In the embedded world because your whole program/environment is loaded from flash into device ram it is very easy (if you have a device with network connectivity) to have a RPC to download and reflash new firmware - this is very useful for installations where physical access is restricted or unavailable and changes must be made to the firmware.
 
While it is possible to for example remote access (via SSH or some other means) to do system upgrades, I think a "whole-image" approach has some benefits especially when considering critical system deployments.
 
So I have been researching options that may be easily deployed into the Armbian build environment - there are quite a few options I have found (https://wiki.yoctoproject.org/wiki/System_Update), however on looking at all the options the best suited to the Armbian environment is mender.io in my opinion.
It is compatible with block devices (uSD/eMMC), compatible with uboot, has a "secure" and robust update mechanism with fallback, is open source and has agreeable licencing for integration with Armbian/Commerical Products etc.
 
The only downside is that it is currently built for integration with the Yocto project and only has a reference hardware of a Beagle Bone Black. There has been some information provided for custom target/build integration: https://mender.io/blog/porting-mender-to-a-non-yocto-build-system.
After reading this I have made some notes, but I am obviously still learning and feedback from those more experienced than I would be appreciated.
 
1) Partition Layout
At the moment the RESIZE_FS flag in the armbian build enviroment causes the rootfs partition to expand to the whole size of the available device, this can be overwritten to a fixed size at build time. Presumably with some modification to the script it could partition the device as required: https://docs.mender.io/1.0/devices/partition-layout
 
2) Go/mender Client libraries
These should be possible to be added as user-packages in the build stage?
 
3)uBoot Patches:
0001-Generic-boot-code-for-Mender.patch
0002-Integration-of-Mender-boot-code-into-U-Boot.patch
 
Should be able to be applied as user uboot patches at build stage?
 
4)Artifact creation (e.g. update images):
Can be completed with an additional post-build script using the mender artifact tool or integrated as an script in Armbian build environment.
 
I suppose my questions are:
-is there interest in such an addition of this feature into armbian?
-for the people that are well versed in the armbian build environment - is there any potential pinch points for integration?
 
 
 
 

Hi devs,
you are complaining about support nightmare. Microsoft had it much worse, with all possible shitty hardware being introduced without drivers and users expecting it to be supported. Their anwer: "Certified for Windows Vista" with a nice icon to be printed on the sales page. Conditions for the hardware vendor to include the icon was defined by Microsoft.
 
No hardware vendor will read the complaints in your forum. Armbian on the other side has quite the reputation. Do the same, define conditions for boards to be "Certified for Armbian" and push the vendors your way.
 
best,
gnasch

Hi devs,
you are complaining about support nightmare. Microsoft had it much worse, with all possible shitty hardware being introduced without drivers and users expecting it to be supported. Their anwer: "Certified for Windows Vista" with a nice icon to be printed on the sales page. Conditions for the hardware vendor to include the icon was defined by Microsoft.
 
No hardware vendor will read the complaints in your forum. Armbian on the other side has quite the reputation. Do the same, define conditions for boards to be "Certified for Armbian" and push the vendors your way.
 
best,
gnasch

I was not talking about votes/polls. I was talking about why we behave like idiots and start to support boards solely based on the fact that a hardware vendor sent us dev samples worth few bucks.
 
Again (!!!) two examples: https://forum.armbian.com/index.php?/topic/4378-nightly-images/&do=findComment&comment=33601 (why do we start with something like Orange Pi Zero Plus 2 H5, it makes absolutely no sense at all --> Armbian no, Android yes/don't care)
 
Again (!!!) my proposal is not to start as soon as someone sends us hardware but to open a new thread in not yet existing 'Board Bring Up Discussion' subforum. There the person who's interested in a specific device has to elaborate on why it would be a good idea to support the specific hardware or whether it's not (vendor behaviour being one of the potential reasons. If a vendor doesn't provide correct specs/schematics, advertises with wrong numbers, doesn't fix documentation mistakes even if told multiple times, sends out partially defective dev samples, doesn't document timely if he exchanged relevant hardware parts -- I'm talking about AP6212 vs. AP6212A here -- that's a good reason to avoid that hardware and document this at the same time so surprised users get the idea why developers consider dealing with a specific hardware not worth their time. That way we might even see some vendors improving over time if their irresponsible behaviour is documented again and again).
 
I'm still only talking about a group decision based on a real discussion when/whether to start working on a device or not. No polls/votes, especially no user polls! If tomorrow a hypothetical 'PicoPi Bullcrap' for $5 is announced immediately 1000 new users sign up here and vote for Armbian support. We already experienced in the past that the cheaper the device the cheaper some people behave.
 
If Armbian might start such a transparent discussion process and users feel they need to ignore developer reasoning then they can start a poll thread on their own asking for a specific new donate button. And then later they're able to vote for board support by donating the amount of cash they were talking about in the first place. That way it's also ensured that we won't start on 'PicoPi Bullcrap' ever since those people only buying as cheap as possible are also too cheap to donate a single Cent.
 
And again: Board bring up is fun, board support the more boring part consuming time, energy and resources. We should triple check whether devices are worth getting 'supported' status or not. That's why I already talked about .playground vs. .wip. Allows developers to focus on fun stuff without risking to waste later time on the boring part. But as we could see with OPi 2G-IoT that does not even work with .wip boards
 

Hi Bruno
 
Armbian seem to offer only "server" distros for the pi zero which means without GUI.
I do not have zero, but opi pc plus for which armbian "desktop" exists.
you might try:
# apt-get install lightdm
followed by:
# service lightdm start
 
But it would be easier if you get an opi for which a desktop armbian exists.
best, gnasch
 
 

Solusion for overlayroot in Armbian Jessie:
 
1) install overlayroot_0.27ubuntu1.4_all.deb
dpkg -i overlayroot_0.27ubuntu1.4_all.deb
 
2) add following lines to /usr/share/initramfs-tools/hooks/overlayroot file:
 
copy_exec /bin/grep /bin
copy_exec /usr/bin/stat /bin
copy_exec /bin/echo /bin
 
This will load missing tools required by /usr/share/initramfs-tools/scripts/init-bottom/overlayroot script.
 
3) replace all "mount --move" with "mount -o move" in /usr/share/initramfs-tools/scripts/init-bottom/overlayroot file.
 
4) update-initramfs -u
 
:-)
overlayroot_0.27ubuntu1.4_all.deb

Any of you have such a beautiful problem?
They like Orange Pi's, they are hot !
 
 
 
 

Hello
 
change language
 
best,
gnasch

I've got the RTL8723bs working using a temporary build of 4.12 ...
 
 

Hi All,
 
I recently bought a cheap 16 character, 2 row LCD display from aliexpress.com for use with my Orange Pi PC. I got it to work without too much pain, but I thought I would document it here for the benefit of others. Some good instructions are already available on the internet, but there are some tweaks required for the Orange PI.
 
Armbian I believe already has the I2C module compiled into the kernel directly. So no Linux Kernal insmod work required, unlike what many Raspberry PI guides seem to imply.
 
Step 1) Buy the things you will need.
 
1. You obviously need a 1602 LCD module which also comes with the the I2C converter. You can buy a 1602 LCD and wire it directly to the 16 GPIO pins required if you want, but that isn't the point of this guide.
2. You will need a level shifter. The LCD display works on +5volts. The OrangePI/H3 GPIO pins are 3.3 volts. I have seen guides stating that you don't need a level shifter, but I'm sure you're slowly frying some transistors in your OrangePI over time.
3. You will need a bunch of jumper cables etc. Like these, female to female only required really.
 
Step 2) Wire things up accordingly.
Thanks to this fantastic guide, the instructions on wiring the Orange PI to the Level Shifter LV ('low voltage') pins, and then the Level Shifter HV ('high voltage') pins to the 1602 I2C module is pretty clear: http://www.raspberrypi-spy.co.uk/2015/05/using-an-i2c-enabled-lcd-screen-with-the-raspberry-pi/
 
 
Level Shifter OrangePI 1602 I2C Backpack LV 3.3V (pin 1) – LV1 SDA (pin 3) – LV2 SCL (pin 5) – GND GND (pin 6) GND HV 5V (pin 2) VCC HV1   SDA HV2   SCL  
Note, you connect the 1602 I2C module/backpack directly to the 5Volt Pin on the PI (Pin 2 or 4) and Ground (Pin 6) respectively.
 
Note: For some strange reason the level shifter works if you don't connect the ground pins to either side of it (i.e. Use the LV, LV1, LV2, HV, HV1 and HV2 pins only). No idea why - electrical engineering degree required I think.
 
If all works well, you should see the LCD module light-up with the top row being a bunch of white bars (you might need to check the contrast setting of the module as well). White bars = uninitialised LCD screen.
 

 
Step 3) Install the required packages int Armbian
Reference:  https://www.abelectronics.co.uk/kb/article/1061/i2c--smbus-and-armbian-linux
sudo apt-get install -y python-smbus i2c-tools Step 4) Check to see what the address of the LCD Screen is:
 
Reference: http://www.raspberrypi-spy.co.uk/2014/11/enabling-the-i2c-interface-on-the-raspberry-pi/
user@orangepipc:~/Downloads/i2c$ sudo i2cdetect -y 0 [sudo] password for userpi: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 3f 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- user@orangepipc:~/Downloads/i2c$ sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Looks like it's 0x3f as the address on I2C bus 0 (which is apparently right according to the aliexpress buyer feedback comments)
 
Step 5) Download Example Script
 
Reference: http://www.raspberrypi-spy.co.uk/2015/05/using-an-i2c-enabled-lcd-screen-with-the-raspberry-pi/
 
The example script will allow you to send text to the screen via I2C. It is very similar to my scripts for the normal 16×2 screen. To download the script directly to your Pi you can use :
 
wget https://bitbucket.org/MattHawkinsUK/rpispy-misc/raw/master/python/lcd_i2c.py  
Step 6) Adjust the Sample Script
 
I need to adjust the script to reference a 1602 LCD device with address 0x3f, on Orange Pi PC I2C Bus, 0. The script as it is references a device of 0x27 on Bus 1 - it won't work. You might have a LCD device of address 0x27 (you'll know from the previous step), but it seems many of the cheap LCD modules from aliexpress are 0x3f for some reason.
 
Adjusted script below:
 
#!/usr/bin/python #-------------------------------------- # ___ ___ _ ____ # / _ \/ _ \(_) __/__ __ __ # / , _/ ___/ /\ \/ _ \/ // / # /_/|_/_/ /_/___/ .__/\_, / # /_/ /___/ # # lcd_i2c.py # LCD test script using I2C backpack. # Supports 16x2 and 20x4 screens. # # Author : Matt Hawkins # Date : 20/09/2015 # # http://www.raspberrypi-spy.co.uk/ # # Copyright 2015 Matt Hawkins # # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation, either version 3 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program. If not, see <http://www.gnu.org/licenses/>. # #-------------------------------------- import smbus import time # Define some device parameters I2C_ADDR = 0x3f # I2C device address LCD_WIDTH = 16 # Maximum characters per line # Define some device constants LCD_CHR = 1 # Mode - Sending data LCD_CMD = 0 # Mode - Sending command LCD_LINE_1 = 0x80 # LCD RAM address for the 1st line LCD_LINE_2 = 0xC0 # LCD RAM address for the 2nd line LCD_LINE_3 = 0x94 # LCD RAM address for the 3rd line LCD_LINE_4 = 0xD4 # LCD RAM address for the 4th line LCD_BACKLIGHT = 0x08 # On #LCD_BACKLIGHT = 0x00 # Off ENABLE = 0b00000100 # Enable bit # Timing constants E_PULSE = 0.0005 E_DELAY = 0.0005 #Open I2C interface bus = smbus.SMBus(0) # Rev 1 Pi uses 0 (and Orange PI PC, for pins 3 and 5) #bus = smbus.SMBus(1) # Rev 2 Pi uses 1 def lcd_init(): # Initialise display lcd_byte(0x33,LCD_CMD) # 110011 Initialise lcd_byte(0x32,LCD_CMD) # 110010 Initialise lcd_byte(0x06,LCD_CMD) # 000110 Cursor move direction lcd_byte(0x0C,LCD_CMD) # 001100 Display On,Cursor Off, Blink Off lcd_byte(0x28,LCD_CMD) # 101000 Data length, number of lines, font size lcd_byte(0x01,LCD_CMD) # 000001 Clear display time.sleep(E_DELAY) def lcd_byte(bits, mode): # Send byte to data pins # bits = the data # mode = 1 for data # 0 for command bits_high = mode | (bits & 0xF0) | LCD_BACKLIGHT bits_low = mode | ((bits<<4) & 0xF0) | LCD_BACKLIGHT # High bits bus.write_byte(I2C_ADDR, bits_high) lcd_toggle_enable(bits_high) # Low bits bus.write_byte(I2C_ADDR, bits_low) lcd_toggle_enable(bits_low) def lcd_toggle_enable(bits): # Toggle enable time.sleep(E_DELAY) bus.write_byte(I2C_ADDR, (bits | ENABLE)) time.sleep(E_PULSE) bus.write_byte(I2C_ADDR,(bits & ~ENABLE)) time.sleep(E_DELAY) def lcd_string(message,line): # Send string to display message = message.ljust(LCD_WIDTH," ") lcd_byte(line, LCD_CMD) for i in range(LCD_WIDTH): lcd_byte(ord(message[i]),LCD_CHR) def main(): # Main program block # Initialise display lcd_init() while True: # Send some test lcd_string("RPiSpy <",LCD_LINE_1) lcd_string("I2C LCD <",LCD_LINE_2) time.sleep(3) # Send some more text lcd_string("> RPiSpy",LCD_LINE_1) lcd_string("> I2C LCD",LCD_LINE_2) time.sleep(3) if __name__ == '__main__': try: main() except KeyboardInterrupt: pass finally: lcd_byte(0x01, LCD_CMD)  
Step 7) ADD YOUR USER ACCOUNT TO 'i2c' GROUP
 
This is a really useful thing to do, otherwise you'll need to run the python script as ROOT (via. sudo etc.) every  time. No good if you want to write a python script that runs using your normal user account and sends messages over I2C to the LCD.
 
Reference: https://www.abelectronics.co.uk/kb/article/1061/i2c--smbus-and-armbian-linux
sudo adduser <YOUR_USER_ID> i2c eg: sudo adduser johnsmith i2c  
Step 8) Run your script!
 
python lcd_i2c.py Amazing!
 

 
Please note: You can probably use a more advanced library to output data to the LCD, but for now, it probably isn't required:
https://gist.github.com/DenisFromHR (you will need to adjust the code in 'RPi_I2C_driver.py' to refer to port=0, not port=1 to get this to work. Also change the address of the LCD device if required)
http://www.circuitbasics.com/raspberry-pi-i2c-lcd-set-up-and-programming/ 
 
What a level shifter looks like:
 

From a usability point of view the behaviour we implemented in Armbian is just an insane fail. There's a 80x25 screen completely filled with absolutely useless data at this point (where those two jelling lines in red somewhere in the middle are lost) and even the informative message trying to guide through the task the user should cope with now is f*cked up (it's line 1 at the top talking about required password change and lines 24-25 continuing with this).
 
I never liked this motd stuff (display of fancy data delaying login) but it should be obvious that displaying this stuff here is counterproductive. But we're simply too blind to realize. If there's a need to reboot why not adding this to the end of user creation: Checking whether reboot is needed or not, telling the user that a reboot is necessary with one option 'reboot' requiring [enter]. No more hassles. And all the irrelevant motd stuff becoming active only on 2nd boot.