bozden

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:
 

In my opinion NOT since this thread here contains a lot of confusing discussions that are Armbian internal and only reflect a specific situation now. I'll repost soon in new 'Board Bring Up' subforum, copy&paste the hardware part, the software support part and try to summarize dev thoughts on current situation as neutral as possible.
 
IMO it's important to keep 'Board Bring Up' threads focused on the board if we want to use this later as 'landing pages' for users (Google is pretty fast: 'armbian banana pi r2' search already lists new thread as hit N° 2)

This is ROCK64 specific. New board with correctly working USB3 arrived 10 minutes ago. Switched to performance governor and doing the usual 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' with the slowest SSD I have lying around (Intel 540):
random random kB reclen write rewrite read reread read write 102400 4 10794 14075 18413 14337 12084 13125 102400 16 38316 48250 58929 50123 33636 44383 102400 512 85148 113573 217972 226149 209220 229556 102400 1024 239054 254531 226798 261436 240226 213082 102400 16384 271696 291983 316979 323006 282067 292218 In other words: this is the new single drive NAS board. Forget about overpriced fails or slow A20 boards or their R40/V40 successors currently only available from brain damaged retards.

To be honest, I didn't need to talk to anyone before contributing/trying to contribute.  The Tinker Board is an excellent example of a board that has some pretty severe vendor-caused support issues in general, ticking off nearly every box from some of the earlier posts.  In this case I had one, I cloned the build system after following the proper documentation to set up a VM on my main computer, and got to work.  I then submitted pull requests on github with my changes.  I don't think a discussion about officially supporting a board is frictional to getting new devs, but I think seeing devs get dogpiled for support requests is.  That was my 100% biggest concern about getting involved, the questions I simply can't answer because I'm a low-level (firmware, micros, assembly, etc) programmer, not necessarily even a well-versed linux kernel guy (learning quickly, but there is a lot there to learn). 
 
 
I'm afraid that's impossible to stop.  "Joe SBC" will invariably try to make a $8 device do the work of a $50 device.  Managing expectations is most likely more difficult than supporting hardware.  While it will upset the low-information DIY-er, I think you'll find collecting such requests/feedback into dedicated "rubbish threads" that link to the FAQ and disclaimers won't be detrimental to the project.  More moderator work.
 
For supporting new boards, as long as the user community (those with no intention to develop) understands and respects that the dev users (anyone willing to code/organize/troubleshoot/brainstorm/document have final say over supporting a board (their work, their decision), then all transparent discussion is of course the preferred method.  I do like the headstone method of having an OP of a thread contain the status/updates/issues of a board, then mark it as EOL and maybe lock the thread.  
 
@tkaiser, I like the OP in this thread, and considering improved moderation that would be a good way to get the information.  It can be done just as easily publicly as privately, getting the weigh-in of the typical dev, I just know that sometimes I have opinions of things that may offend vendors or even users, e.g. "Well if you're stupid enough to do that, I'm not going to be any help" .
 
I've been dabbling with websites and projects for almost 20 years now (I started young), the biggest problem I see with the free exchange of ideas that is the forum is burying data in clutter.  A 20 page thread will have, literally, 2 pages of useful content.  This is simply due to agreement, question, additional thought, etc.  This is why Forums are terrible archived documentation/reference sources.  It's very easy to blame it on the user when they re-pose questions, since a proper search can find the information, but often it turns into wading through pages of nonsense and unrelated tidbits to get the command, or parameter, or info you wanted.  I believe a more constructive method involves the Forum as an idea development/collaboration platform that said information is then culled from and formalized in some manner.  I would recommend something like below:
 
For a new Board, exactly as tkaiser opened the discussion, updating as new information becomes available.  Once a decision has been made by the team (I would assume a dev or two would have to more or less "adopt" the board in question for hardware support), close the thread, maybe clean it of extraneous info if mods haven't been doing that actively, and archive it as reference on a wiki, or transfer its information to a wiki and link to an archived PDF/html/whatever of the original, maintaining the conversation, but not allowing it to get buried or cause a huge amount of "pinned" topics you have to drill through to get to "live" discussions.
 
Upon officially declaring a board to be supported, have a subforum for the board (I know, huge effort organizing), then open a discussion/debugging thread for each release.  Lock that thread upon release and open a bugfixing thread, etc.  Keep the last release or two on the forum as immediate reference, archive the rest as HTML/PDF/Whatever available via a Wiki page for the board.  A "Hardware Support Status" table on a wiki would be ideal, just simple Green/Yellow/Red next to the supported bits per kernel, a simple visual aid goes a long way.  I would include an * or <- or some other mark with a note about special patching if it's needed (WiFi on Tinker Board Kernel 4.4 as an example)
"Official" Forum threads need to be consistently titled (example/proposal):
 
[Pre-Release 5.31] Hardware Feature Request
[Release Candidate 5.31] Bug Reporting
[Release 5.31] Continuing Support  
 
 
Now, boards may come about that initially seem like a great idea, check the boxes, but which later turn out to be piles of garbage.  I would recommend having a mandatory "trial period" for a board before committing to support it, no matter how perfect it might seem.  (Call it "Maybe-an"?  )  Again, personal experience here, the Tinker Board BT, SD power supply, and MAC address issues all require hacking up the kernel in a not easily supportable way or writing our own drivers.  Some of that wasn't obvious until the Rockchip/ASUS team released the source for their kernel.  In a situation like this, a discussion needs to happen concerning how to support and if/why to support moving forward.  I would personally wait another cycle for the next release and see if any more mainline work is done on the part of the vendor.  If not, we need to decide if something as ridiculous as making the board capable of rebooting properly is our responsibility/interest.  Other boards, I'm sure, are similar.
 
My apologies for rambling.

Thank you for this... This is a quite valuable resource...

Conclusions:
 
- nightly kernel and BSP building yes, nightly images once per week
- focus more to provide simpler way for new developers to get in
- nightly images should be carefully picked to provide best "price performance" ratio
 
and another proposed actions:
 
- moving another three boards (Lamobo R1 / Cubieboard 1 / Lime A10) into deprecated sessions. All those boards get one last update with last known working configuration and frozen kernel packages
 
 
This a current project overview, which we try to follow. Is this time span perfectly o.k. ? Not sure. We will need to adjust it in the future, but it’s something to go with and stick to it, when and if we agree:
 
UPCOMING MILESTONES
Milestone Responsible Person Due On Feature developement --- Due in 81 Days Feature freeze --- Due in 90 Days Beta testing and bug fixing --- Due in 130 Days Writing release documentation --- Due in 142 Days Launch --- Due in 149 Days Withing project management we manage to establish fully operating testing system – a person get’s an email, when and what to test – his report is clicking few check boxes + adding a note when necessarily. Technology was tested twice and it works, methodology needs broad discussion. Project manager is the one, who has overview and drive (volunteer) developers to fix this and that. In reality this means I was driving myself and Michael was assisting in this and solving problems which are out of my league. Since we were also testers, most of bugs were saved already on the way ...
 
 
Project management is yet another full time position, which waits to be filled developed and filled in. We deliberately use this hidden, because I was not sure if it’s the right way to go, because not everybody needs to  be involved in everything and because not finished products are better to hide. Check email.
 
Until there is no somebody who will take a full lead on this, I am moving it forward with (my) highest possible speed. Well, in fact it's already we. Tido is helping in this beta trial process.
 
 
We can add text to forum description, which board are officially supported – I know people will still fail to see.
 
 
Yes. This is at least much simpler to support and is to consider.
 

Yeah. At least we are highly motivated to end / limit at best as possible.
 
 
We would certainly need more moderators, which would take care of such questions appropriately. Technical knowledge about those boards is not a requirements. If @chwe wants to take care of general moderator duties, he is one click away
 

This is fine, but very hard to maintain.
 
The rest elsewhere. This one is already off topic.

Put up a "bounty" have those who wish to have a board supported or a feature added, have them put up some funds, plus the boards.
I donated because I find the process entertaining, gives my brain something to do, but if I had a project I could see paying for a feature or 2.
 
You guys need to offer more "fun", ...more projects which will draw in programmers and end users.
I see a bunch of folks hoping to do projects that are really pushing these boards, how about some IOT projects, Magic mirror, leggo bots an so on.
 
Igor's menu is a good start for those just starting out (reminds of Doug's menu for IBM DOS).
 Maybe offer access to the scripts, so folks can alter / add to it.

That may be hard, but I just checked mpp source (Rockchip HW video acceleration library) and it mentions that RK3328 is fully supported. Rockchip kernel 4.4 also has initial support for video decoding. I would say that future is bright.

I have to close the door when I'm soldering. My black cat only walks by but my whitevone tries to catch the iron and the cables...
 
 
Edit: typo.
 
 
Enviado desde mi Jolla mediante Tapatalk
 
 
 
 

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

Yes, keeping them out when soldering is a must.
Jumper cables, LED's, buttons, sensors - no matter what I plug - they are "game" (in both meanings).
And I need to recheck breadboards in every test run.

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

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

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

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

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

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

Yes, that is what I wrote to OPi forums. I think the point they have is "we boosted it, cool it - or underclock it to reverse". The Zero's were already hot and they made them hotter. Not suitable for summer projects  
 
I never used WiFi on these boards yet as I read about the performance in your tests.
I'll test them whenever possible with similar setup like your tests. I'm working with OPi One's now and I have to finish them first.
 

Yes, that is what I wrote to OPi forums. I think the point they have is "we boosted it, cool it - or underclock it to reverse". The Zero's were already hot and they made them hotter. Not suitable for summer projects  
 
I never used WiFi on these boards yet as I read about the performance in your tests.
I'll test them whenever possible with similar setup like your tests. I'm working with OPi One's now and I have to finish them first.
 

The thumb on #3 belonged to my son  It also burned, my son could just say "15 Mississippi" before shouting... 
On #1 I used my little finger, there the skin is thinner
 
I'll try all 3 later after by burns heal
 

For SBC to provide USB3 either the SoC has to be USB3 capable or the SoC needs a high speed bus (like PCIe) to attach an USB3 controller to it (which would be wrong if the SoC has just a single PCIe lane since then you don't use USB3 but SATA instead). That's why Armbian currently only supports the following boards with USB3:
 
LeMaker Guitar and Roseapple Pi (Actions Semi S500 is USB3 capable but performance and software support are a sh*t show and Ethernet there is Fast Ethernet only --> forget about NAS use cases) Clearfog Base / Clearfog Pro (always wrong to use USB3 here since they feature native SATA -- performance numbers/comparison) ODROID XU4 (too expensive, technically questionable since everything is USB there, an internal USB hub is always between host controller and disks and host controller as well as recommended peripherals have their own issues paired with a user base trapped in a micro community rejecting reality) Hummingboard (you could add USB3 via a mPCIe card here but this would be wrong since this board has native SATA but limited Gigabit Ethernet so NAS performance is even lower than what cheap USB2/GbE H3/H5 boards provide)  
What's coming soon with USB3:
 
EspressoBin (using USB3 here is just wrong since the board features native SATA -- even up to 3 ports by adding a cheap ASM1062 mPCIe card). Status: ready soon Helios4 (4 x SATA so why thinking about the 2 x USB3? ): Status: ready soon (the board is on Kickstarter the next 4 weeks) Rock64 (not even announced using Quad core Cortex-A53 RK3328 with native Gigabit Ethernet and USB3). Status: unknown but if price and SDK looks good there's no doubt Armbian will support it Rockchip RK3399 based devices (like this): Status: not even really announced, IMO uninteresting since way too expensive Boards based on Allwinner H6 (Quad core Cortex-A53, new 28nm process, 1 x USB3, PCIe 2.x x1 so you could avoid USB3 and use SATA through an ASM1061 instead). Status: nothing announced yet but if price and SDK looks good there's no doubt Armbian will support it (speaking of 2018)  
In other words: for NAS use cases forget about USB3 now and in the foreseeable future, choose EspressoBin if you want both affordable and fast or choose the combination H3/H5+GbE+USB2. Only potential exception from the USB3 rule: Rock64 soon and maybe later Allwinner H6 based boards.
 
(Allwinner A20/R40 boards not mentioned by intention since too slow and especially R40 at the moment close to unusable since the only board available is from SinoVoip so no vendor support and most probably documentation/schematic f*cked up as usual)
 
 

Yes, we promote Ubuntu with a reason - Ubuntu Xenial has more recent and polished package base with less troubles than Debian Jessie. In desktop area we ran into enough troubles which lead to abandoning support for Debian desktop versions, while server remain fully supported. If there are no download options, you need to build it on your own.
 
When Debian moves to Stretch, we plan to follow and situation will most likely turn in favour of Debian.

On the back side of OPiOne PCB you can find also TVOut signal and MUTE which is used to disable audio amplifier but of course OPiOne has no such on board and even OPiPC had this unit removed.

Same way like above it is easy to expand OPiOne adding missing analog audio, mic and IR receiver.
1 - IR receiver RX line
2,3,4 - MIC1P/MIC1N/MIC-MBIAS
5,6 - LINEOUTR/LINEOUTR
Look at Orange Pi PC schematics to find out what extra components should be used to obtain full OPiPC functionality.

Orange Pi One PCB is designed to easy add almost all removed features from Orange Pi PC. Currently only RAM expansion is unprofitable.
To add 2 removed USB ports just solder wires to solder points as shown below on the photo:
Data lines for USB #3: points 1,2
Data lines for USB #2: points 3,4
Power can be taken directly from GPIO header or DC socket. OPiOne has no separate voltage regulators for USB ports like previous boards used to have.
This way I want to solder mini WiFi dongle (after removing the case and USB port) directly to the PCB.