Jump to content

AnonymousPi

Members
  • Posts

    35
  • Joined

  • Last visited

Reputation Activity

  1. Like
    AnonymousPi got a reaction from gounthar in Is GPIO on H3 SoC really this slow?   
    Refer to this C library: https://github.com/luoyi/h3-gpio which seems quite fast, and read this comment.
     
    It appears 10Mhz should be doable, but only if you do not read the value of the GPIO. So cache the latest value of the GPIOs locally in your code as a local variable if say, you need to do bit manipulation.
     
  2. Like
    AnonymousPi got a reaction from manuti in How to enable RDP (xrdp) with Armbian so you can login from a Windows PC   
    Update, for whatever reason this is broken in Armbian focal, and the issue appears to be due to an Armbian shell script that xrdp doesn't like, so after doing the install, you also need to then do:
    sudo mv /etc/profile.d/armbian-check-first-login.sh /etc/profile.d/armbian-check-first-login.old And volia, you'll actually get a desktop when you RDP from windows.
  3. Like
    AnonymousPi got a reaction from TonyMac32 in 64x32 LED MATRIX with Allwinner H3 / Orange PI PC   
    A very hackish port exists of this Raspberry PI RGB LED Matrix Library which works for Allwinner H3 devices. This works by bit-banging 14 GPIO pins simultaneously to achieve about a 10Mhz throughput / 100fps refresh rate.
     
    Refer to here: https://github.com/mrfaptastic/opi-allwinner-h3-rgb-led-matrix
     
    I managed to easily get up and running using an Orange PI. Refer to the README of the github repository.

  4. Like
    AnonymousPi got a reaction from borekon in Configuring Orange PI PC to receive IR/InfraRed   
    Note: Guide Updated May 2017, as I realise that /dev/input/event3 may not always be the IR receiver device on your armbian installation.
     
    Hi All,
     
    I recently bought an Orange PI PC and the best thing I ever did was install Armbian straight away (and donate). Now that I have a bit of spare time, I wanted to configure my Orange PI PC to do something ridiculous like play Rick Ashley 'Never going to give you up' upon pressing the 'red button' on some generic Chinese IR remote for an LED light strip I have in my living room.
     
    Thanks to Armbian, most of the pieces are in place (such as the SunXI IR package) with the distribution, you just need to glue it all together.
     
    However there are few configuration issues with the default Armbian install on the Orange PI PC that need to be adjusted, otherwise you'll encounter infuriating issues such as:
    No IR device existing or being detected (root cause: sunxi-cir module not loaded) No LIRC 'irw' output even after successfully using irrecord (root cause: DRIVER=devinput doesn't work, though it could be my remote), like this poor sod was experiencing.  
    I should also note that this guide on the terrible Orange PI forums, helped me with my issues.
     
    Step 1) Adjust /etc/lirc/hardware.conf
     
    Updated: This guide was originally written for Armbian based on Debian 'Jessie'. The latest Armbian (as at September 2017) is now based on Ubuntu Xenial. This introduces a new lirc package which yet again comes with a broken hardware.conf
     
    For Ubuntu Xenial (September 2017):
     
    The default hardware.conf that comes with Armbian is broken. It's assigning the 'remote' and 'transmitter' to the same device, this breaks everything. Ensure the TRANSMITTER_MODULES="" and TRANSMITTER_DEVICE = ""
    # /etc/lirc/hardware.conf # #Chosen Remote Control REMOTE="None" REMOTE_MODULES="sunxi_cir" REMOTE_DRIVER="default" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" # FYI - /run/lirc/lircd will probably be the socket that the system uses REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS="" #Chosen IR Transmitter TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="/dev/null" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS="" #Disable kernel support. #Typically, lirc will disable in-kernel support for ir devices in order to #handle them internally. Set to false to prevent lirc from disabling this #in-kernel support. #DISABLE_KERNEL_SUPPORT="true" #Enable lircd START_LIRCD="true" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false" #Try to load appropriate kernel modules LOAD_MODULES="true" # Default configuration files for your hardware if any LIRCMD_CONF="" #Forcing noninteractive reconfiguration #If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD=""  
    For Debian Jessie (~year 2016):
     
    By default Armbian doesn't have the suxi-cir module enabled at boot-up, but it is available, so you will need to edit hardware.conf to enable this, as well as correct the DRIVER= line and the DEVICE= line, as the defaults in there are WRONG.
     
    Also I suggest commenting out Igor's code in the top five lines. A hardware.conf that works:
    # Cubietruck automatic lirc device detection by Igor Pecovnik #str=$(cat /proc/bus/input/devices | grep "H: Handlers=sysrq rfkill kbd event" | awk '{print $(NF)}') #sed -i 's/DEVICE="\/dev\/input.*/DEVICE="\/dev\/input\/'$str'"/g' /etc/lirc/hardware.conf # /etc/lirc/hardware.conf # # Arguments which will be used when launching lircd LIRCD_ARGS="" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD=false #Don't start irexec, even if a good config file seems to exist. #START_IREXEC=false #Try to load appropriate kernel modules LOAD_MODULES=true # Run "lircd --driver=help" for a list of supported drivers. # 'devinput' driver on Orange PI PC causes NO EVENTS TO OCCUR # via irw for some reason. DRIVER="default" # usually /dev/lirc0 is the correct setting for systems using udev DEVICE="/dev/lirc0" MODULES="sunxi-cir" # Default configuration files for your hardware if any LIRCD_CONF="" LIRCMD_CONF="" Step 2) Restart lircd service
      As lirc is actually already running and installed in Armbian, do the following:
     
    root@orangepipc:/etc# /etc/init.d/lirc stop root@orangepipc:/etc# /etc/init.d/lirc start To reboot the service. 
     
    Then perform an 'lsmod' to see if it loaded the sunxi_cir module (because otherwise nothing will work):
      user@orangepipc:~$ lsmod Module                  Size  Used by mali_drm                2732  1 drm                   178255  2 mali_drm mali                  123208  0 ump                    29379  3 mali sunxi_cir               1601  0 8189es               1076034  0   Step 3) Find out what '/dev/input/eventX' device is your IR receiver   If you do a: ls /dev/input/event* You will most likely get a bunch of possible event devices to choose from, for example:
    anonymouspi@orangepipc:~$ ls /dev/input/event* /dev/input/event0 /dev/input/event2 /dev/input/event4 /dev/input/event1 /dev/input/event3 /dev/input/event5 For my installation, /dev/input/event3 is the IR receiver, but if you have other devices installed (i.e. USB cameras, keyboards etc.) then the number could be different. For example, executing 'evtest /dev/input/event3' reveals:
    Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" A device name of 'sunxi-ir' means that we are using the right device for the purposes of evtest
        Step 4) Do a quick test with with 'evtest' (OrangePI PC armbian seems to use /dev/input/event3 for IR input )   Armbian has the 'evtest' program installed, point the IR remote (in my case a  LED colour remote) at your Orange PI PC and as root 'evtest /dev/input/event3'.   root@orangepipc:/etc# evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" Supported events:   Event type 0 (EV_SYN)   Event type 1 (EV_KEY)     Event code 152 (KEY_SCREENLOCK)   Event type 4 (EV_MSC)     Event code 4 (MSC_SCAN) Key repeat handling:   Repeat type 20 (EV_REP)     Repeat code 0 (REP_DELAY)       Value    500     Repeat code 1 (REP_PERIOD)       Value    125 Properties: Testing ... (interrupt to exit)  
    Pressing the remote reveals events like:
    Testing ... (interrupt to exit) Event: time 1472917554.113967, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 Event: time 1472917554.113981, -------------- EV_SYN ------------ Event: time 1472917554.464390, type 4 (EV_MSC), code 4 (MSC_SCAN), value 59 Event: time 1472917554.464398, -------------- EV_SYN ------------ Event: time 1472917554.842832, type 4 (EV_MSC), code 4 (MSC_SCAN), value 45 Event: time 1472917554.842839, -------------- EV_SYN ------------ Event: time 1472917555.345584, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 That was the red, green, blue and white buttons being pressed. This is a good news.
     
     
    Step 5) Configure lirc to map IR input to key presses or events.
     
    Again, Armbian has irrecord installed (great work Igor), but given I'm re-using this remote to configure the output of a LED strip I have, I'll need to map the IR data sent, to something more meaningful. In other use-cases this isn't generally required as lircs provides a database of media remotes which is pre-mapped to Linux commands/keyboard keys.
     
    There's plenty of information on how to use irrecord, command I used was:
    /etc/init.d/lirc stop ...to first stop the service, then:
    irrecord -H default -d /dev/lirc0 /etc/lirc/lircd.conf ... to record my remote and bind to 'keys'.
     
     
    Step 6) Test with irw
     
    Now that I recorded my configuration file with irrecord:
    /etc/init.d/lirc start .. to start lird service again
     
    then type 'irw' and check that the key mapping works when I point the remote at the Orange PI PC and press a button:
    root@orangepipc:/etc# irw 0000000000ff1ae5 00 KEY_R /etc/lirc/lircd.conf 0000000000ff1ae5 01 KEY_R /etc/lirc/lircd.conf 0000000000ff9a65 00 KEY_G /etc/lirc/lircd.conf 0000000000ff9a65 01 KEY_G /etc/lirc/lircd.conf 0000000000ffa25d 00 KEY_B /etc/lirc/lircd.conf 0000000000ffa25d 01 KEY_B /etc/lirc/lircd.conf 0000000000ff22dd 00 KEY_W /etc/lirc/lircd.conf 0000000000ff22dd 01 KEY_W /etc/lirc/lircd.conf Hoo Ray!
      Step 7) Create a /etc/lirc/lircrc file to run commands
     
    sudo vi /etc/lirc/lircrc I'd actually call mpv here and call the player:
    # http://www.lirc.org/html/configure.html begin    button = KEY_R    prog = irexec    config = mpv  /home/root/Rick\\ Astley\\ -\\ Never\\ Gonna\\ Give\\ You\\ Up.m4a & echo "COMMENT RICK ROLLING" & end begin    button = KEY_W    prog = irexec    config = killall mpv & echo "SADFACE!" & end begin    button = KEY_B    prog = irexec    config = mpv http://sj256.hnux.com & end   You could also create a file for each user of the system if you want, eg: /root/.lircrc, /home/userXXX/.lircrc However if you do this, you will need to start the irexec service manually. If you have a /etc/lirc/lircrc file, the irexec service will start automatically at boot - this service is what actually converts the key press to the command.     So there you go, Rickrolling with a simple press of the red (KEY_R) button :-)  
     
     
    Additional References:
    [Guide] Android + InfraRed (IR) + Kodi 
    How to setup Remote Control for Linux
  5. Like
    AnonymousPi got a reaction from manuti in How to enable RDP (xrdp) with Armbian so you can login from a Windows PC   
    Hi,
     
    There's been a few guides around on how to get RDP working with Armbian so you can login from your Windows or other PC. Some solutions mentioned in various threads here were:
     
    Install tightvncserver instead + x2go bloat (i.e. use VNC) Only login as root - didn't seem to make any difference for me Change some permissions of a log file in your home directory.  
    Well, this is what I did on my Orange PI PC running Buster desktop with Kernel 5.4, as of April 2020.
     
    sudo apt install xrdp xorgxrdp sudo systemctl enable xrdp sudo reboot ... and that was it. The missing piece of the puzzel appeared to be the install of xorgxrdp, this isn't installed automatically by 'xrdp' package, and it's useless without it.

     
    Update June 2020: Also works with RetroOrangePi 4.3 super quickly (given this is based on Armbian Bionic 18.04). Can RDP in and use Armbian Desktop whilst Kodi plays a 4k movie on the TV from the same device... Awesome!
     

     
  6. Like
    AnonymousPi reacted to botfap in Meltdown and Spectre   
    Big digression but:
     
    In regards to @tkaiser negative and pessimistic suggestions to keep dropping board support for problem boards,  I think he is absolutely correct.
     
    While Im not a big Armbian user (we have our own linux based OS stack that we created from scratch and an ubuntu 16.04 derivative we tailored), I do follow its progress quite closely and its clear that there isnt enough engineering resource to support the list of boards that you try to support. Thats not a criticism, its just the reality of any open project. Once you have a board up and running, even at just 25% of completion, every TV Box shitter and their dog wants it all working, right now, on mainline, with 8K support, running from a nokia 3210 charger, etc, etc.
     
    There seems to be enough engineering resource to support about 10 major boards with minor variations. To my mind it would make much more sense and make Armbian a much more valuable project to support less boards to a higher level and to have fully standardised functionality across all "officially" supported boards. Officially supported boards get support for 3/4/5 years or whatever. You dont even try to support a board unless every critical dev on the project has at least one of them.
     
    By standardised Armbian functionality, I mean things like:
    standard Armbian GPIO (+i2c, spi, 1wire, etc) library (@Larry Bank already made a good start here) standard RTC interface, utils and device (we only support 3 RTC drivers) standard NAND interface, layout, device standard GSM interface, utils and device (we only support 5 drivers) standard and predictable network interface naming, handling and utils standard hardware / psu stress test standard sound and video in / out / process utils (standard interface is pretty difficult here I accept) standard remote access interface for cloud control standard config utility standard base OS. pick debian 9 or ubuntu 18.04 for future dev, stop trying to support both (my personal preference is debian but there are good commercial reasons to stick with ubuntu LTS) limited SD card support. dont support any re-badgers (Kingston, entry level sandisk, toshiba, etc ). we only use sandisk extreme plus and sandisk high endurance and have a failure rate of approx 2 in 1000  
    That doesn't mean you cant have another 15 "community" supported boards, but with those there is no promise of full functionality and no official support offered. Those boards need to have community champions (individuals that want to help support specific boards, probably because they have them at home) and automated builds of community supported boards, its just means they dont get factored into long term development planning, support and testing.
     
    What would you rather see from Armbian?
    1) 30+ boards with levels of completion from 20%-95% and different functionality on each (think GPIO, NAND, RTC, GSM, etc)
    2) 10 boards with 90%+ level completion and with standardised Armbian specific functionality across all of them? With 20 more community supported unofficial boards. 
     
    Once you have structure 2 in place then you also have the correct structure to start making money from commercial support offerings. Think Armbian Gold / Pro whatever where you sell commercial support delivered via a cloud interface where the customers can manage all their devices (1-1M) from a web browser. This is what we do.
     
    Controversial suggestion but you should support at least 1 variant of the RasPi. I know the hardware is shit and the RasPi foundation is full of shit but its also the most common SBC on the market. For that reason we do support the RasPi 3 only and while there are concessions to be made we also have roughly 6500 of them on support with our own OS stack at £5/€5 per month per device. We normally manage to get clients off them and onto something better at the next platform refresh.
  7. Like
    AnonymousPi got a reaction from manuti in Configuring Orange PI PC to receive IR/InfraRed   
    Note: Guide Updated May 2017, as I realise that /dev/input/event3 may not always be the IR receiver device on your armbian installation.
     
    Hi All,
     
    I recently bought an Orange PI PC and the best thing I ever did was install Armbian straight away (and donate). Now that I have a bit of spare time, I wanted to configure my Orange PI PC to do something ridiculous like play Rick Ashley 'Never going to give you up' upon pressing the 'red button' on some generic Chinese IR remote for an LED light strip I have in my living room.
     
    Thanks to Armbian, most of the pieces are in place (such as the SunXI IR package) with the distribution, you just need to glue it all together.
     
    However there are few configuration issues with the default Armbian install on the Orange PI PC that need to be adjusted, otherwise you'll encounter infuriating issues such as:
    No IR device existing or being detected (root cause: sunxi-cir module not loaded) No LIRC 'irw' output even after successfully using irrecord (root cause: DRIVER=devinput doesn't work, though it could be my remote), like this poor sod was experiencing.  
    I should also note that this guide on the terrible Orange PI forums, helped me with my issues.
     
    Step 1) Adjust /etc/lirc/hardware.conf
     
    Updated: This guide was originally written for Armbian based on Debian 'Jessie'. The latest Armbian (as at September 2017) is now based on Ubuntu Xenial. This introduces a new lirc package which yet again comes with a broken hardware.conf
     
    For Ubuntu Xenial (September 2017):
     
    The default hardware.conf that comes with Armbian is broken. It's assigning the 'remote' and 'transmitter' to the same device, this breaks everything. Ensure the TRANSMITTER_MODULES="" and TRANSMITTER_DEVICE = ""
    # /etc/lirc/hardware.conf # #Chosen Remote Control REMOTE="None" REMOTE_MODULES="sunxi_cir" REMOTE_DRIVER="default" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" # FYI - /run/lirc/lircd will probably be the socket that the system uses REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS="" #Chosen IR Transmitter TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="/dev/null" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS="" #Disable kernel support. #Typically, lirc will disable in-kernel support for ir devices in order to #handle them internally. Set to false to prevent lirc from disabling this #in-kernel support. #DISABLE_KERNEL_SUPPORT="true" #Enable lircd START_LIRCD="true" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false" #Try to load appropriate kernel modules LOAD_MODULES="true" # Default configuration files for your hardware if any LIRCMD_CONF="" #Forcing noninteractive reconfiguration #If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD=""  
    For Debian Jessie (~year 2016):
     
    By default Armbian doesn't have the suxi-cir module enabled at boot-up, but it is available, so you will need to edit hardware.conf to enable this, as well as correct the DRIVER= line and the DEVICE= line, as the defaults in there are WRONG.
     
    Also I suggest commenting out Igor's code in the top five lines. A hardware.conf that works:
    # Cubietruck automatic lirc device detection by Igor Pecovnik #str=$(cat /proc/bus/input/devices | grep "H: Handlers=sysrq rfkill kbd event" | awk '{print $(NF)}') #sed -i 's/DEVICE="\/dev\/input.*/DEVICE="\/dev\/input\/'$str'"/g' /etc/lirc/hardware.conf # /etc/lirc/hardware.conf # # Arguments which will be used when launching lircd LIRCD_ARGS="" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD=false #Don't start irexec, even if a good config file seems to exist. #START_IREXEC=false #Try to load appropriate kernel modules LOAD_MODULES=true # Run "lircd --driver=help" for a list of supported drivers. # 'devinput' driver on Orange PI PC causes NO EVENTS TO OCCUR # via irw for some reason. DRIVER="default" # usually /dev/lirc0 is the correct setting for systems using udev DEVICE="/dev/lirc0" MODULES="sunxi-cir" # Default configuration files for your hardware if any LIRCD_CONF="" LIRCMD_CONF="" Step 2) Restart lircd service
      As lirc is actually already running and installed in Armbian, do the following:
     
    root@orangepipc:/etc# /etc/init.d/lirc stop root@orangepipc:/etc# /etc/init.d/lirc start To reboot the service. 
     
    Then perform an 'lsmod' to see if it loaded the sunxi_cir module (because otherwise nothing will work):
      user@orangepipc:~$ lsmod Module                  Size  Used by mali_drm                2732  1 drm                   178255  2 mali_drm mali                  123208  0 ump                    29379  3 mali sunxi_cir               1601  0 8189es               1076034  0   Step 3) Find out what '/dev/input/eventX' device is your IR receiver   If you do a: ls /dev/input/event* You will most likely get a bunch of possible event devices to choose from, for example:
    anonymouspi@orangepipc:~$ ls /dev/input/event* /dev/input/event0 /dev/input/event2 /dev/input/event4 /dev/input/event1 /dev/input/event3 /dev/input/event5 For my installation, /dev/input/event3 is the IR receiver, but if you have other devices installed (i.e. USB cameras, keyboards etc.) then the number could be different. For example, executing 'evtest /dev/input/event3' reveals:
    Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" A device name of 'sunxi-ir' means that we are using the right device for the purposes of evtest
        Step 4) Do a quick test with with 'evtest' (OrangePI PC armbian seems to use /dev/input/event3 for IR input )   Armbian has the 'evtest' program installed, point the IR remote (in my case a  LED colour remote) at your Orange PI PC and as root 'evtest /dev/input/event3'.   root@orangepipc:/etc# evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" Supported events:   Event type 0 (EV_SYN)   Event type 1 (EV_KEY)     Event code 152 (KEY_SCREENLOCK)   Event type 4 (EV_MSC)     Event code 4 (MSC_SCAN) Key repeat handling:   Repeat type 20 (EV_REP)     Repeat code 0 (REP_DELAY)       Value    500     Repeat code 1 (REP_PERIOD)       Value    125 Properties: Testing ... (interrupt to exit)  
    Pressing the remote reveals events like:
    Testing ... (interrupt to exit) Event: time 1472917554.113967, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 Event: time 1472917554.113981, -------------- EV_SYN ------------ Event: time 1472917554.464390, type 4 (EV_MSC), code 4 (MSC_SCAN), value 59 Event: time 1472917554.464398, -------------- EV_SYN ------------ Event: time 1472917554.842832, type 4 (EV_MSC), code 4 (MSC_SCAN), value 45 Event: time 1472917554.842839, -------------- EV_SYN ------------ Event: time 1472917555.345584, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 That was the red, green, blue and white buttons being pressed. This is a good news.
     
     
    Step 5) Configure lirc to map IR input to key presses or events.
     
    Again, Armbian has irrecord installed (great work Igor), but given I'm re-using this remote to configure the output of a LED strip I have, I'll need to map the IR data sent, to something more meaningful. In other use-cases this isn't generally required as lircs provides a database of media remotes which is pre-mapped to Linux commands/keyboard keys.
     
    There's plenty of information on how to use irrecord, command I used was:
    /etc/init.d/lirc stop ...to first stop the service, then:
    irrecord -H default -d /dev/lirc0 /etc/lirc/lircd.conf ... to record my remote and bind to 'keys'.
     
     
    Step 6) Test with irw
     
    Now that I recorded my configuration file with irrecord:
    /etc/init.d/lirc start .. to start lird service again
     
    then type 'irw' and check that the key mapping works when I point the remote at the Orange PI PC and press a button:
    root@orangepipc:/etc# irw 0000000000ff1ae5 00 KEY_R /etc/lirc/lircd.conf 0000000000ff1ae5 01 KEY_R /etc/lirc/lircd.conf 0000000000ff9a65 00 KEY_G /etc/lirc/lircd.conf 0000000000ff9a65 01 KEY_G /etc/lirc/lircd.conf 0000000000ffa25d 00 KEY_B /etc/lirc/lircd.conf 0000000000ffa25d 01 KEY_B /etc/lirc/lircd.conf 0000000000ff22dd 00 KEY_W /etc/lirc/lircd.conf 0000000000ff22dd 01 KEY_W /etc/lirc/lircd.conf Hoo Ray!
      Step 7) Create a /etc/lirc/lircrc file to run commands
     
    sudo vi /etc/lirc/lircrc I'd actually call mpv here and call the player:
    # http://www.lirc.org/html/configure.html begin    button = KEY_R    prog = irexec    config = mpv  /home/root/Rick\\ Astley\\ -\\ Never\\ Gonna\\ Give\\ You\\ Up.m4a & echo "COMMENT RICK ROLLING" & end begin    button = KEY_W    prog = irexec    config = killall mpv & echo "SADFACE!" & end begin    button = KEY_B    prog = irexec    config = mpv http://sj256.hnux.com & end   You could also create a file for each user of the system if you want, eg: /root/.lircrc, /home/userXXX/.lircrc However if you do this, you will need to start the irexec service manually. If you have a /etc/lirc/lircrc file, the irexec service will start automatically at boot - this service is what actually converts the key press to the command.     So there you go, Rickrolling with a simple press of the red (KEY_R) button :-)  
     
     
    Additional References:
    [Guide] Android + InfraRed (IR) + Kodi 
    How to setup Remote Control for Linux
  8. Like
    AnonymousPi got a reaction from gregvp in Using 16x2 ('1602') LCD with I2C connector with Orange Pi PC   
    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:
     

  9. Like
    AnonymousPi got a reaction from gregvp in Configuring Orange PI PC for analogue Line-Out jack audio output (and Simultaneous HDMI output with Software Mixing)   
    Hi All,
     
    After I accomplished my IR Red Key Rick Rolling experiment the other day with much success, and from general end-luser use with Armbian, there were two things which irritated me, which are namely due to the default ALSA configuration that comes with stock Debian and that Armbian inherits. These were:
     
    Update: 11 September 2017. This guide will not work for newer Armbiam (Debian) installations which comes with Pulseaudio by default. If you really want what this tutorial provides, you will need to uninstall pulseaudio first: sudo apt-get remove pulseaudio
     
    1) You can't have simultaneous applications using an Audio device. So, how about if I want to stream Internet Radio with 'Radio Tray' but also get system alert sounds, or anything else? Out of luck, you'll get (for example):
    [ao/alsa] Playback open error: Device or resource busy 2) I want to actually have audio going out of the 3.5mm jack (don't really care about video out), better still if it's the same/simultaneous to what is going out via. HDMI. That means if I have a HDMI TV connected then I can get the sound from the TV, if I don't, then I can just use the 3.5mm jack (i.e. If I'm using my Pi to play Rick Astley headless/without a TV). No need to keep editing /etc/asound.conf every time.
     

     
    Solution?
     
    Step 1) Fix the mute on the analog Line-Out in alsamixer (for a start)
     
    There's a lot of noise out there about people not being able to get any sound our of the analog Line-Out jack even when having changed /etc/asound.conf. The reason for this is likely due to a mute by default on the analog audio line-out (i.e. the 3.5mm headphone jack) in alsa that you would unlikely to be aware of. I only found this out thanks to a comment here, otherwise I would have thrown by Pi PC out the window today.
     
    So to fix, you need to type in the console:
    sudo alsamixer Then F6 select the 'audiocodec', then tap the right arrow key to select the 'Audio lineout [Off]' item.
     

     
    Press 'm' and you'll get the green 'OO', which means it's now active.
     

     
    Exit alsamixer, and when you're back at the console type:
    sudo alsactl store 0 ... to store you mixer settings.
     
    For your information, the mixer settings are stored to the file:
    /var/lib/alsa/asound.state  ... and if you do a diff of this file after having made the changes in alsamixer, this is what is changed in the alsa asound.state file:
           control.9 {                                                     control.9 {                 iface MIXER                                                     iface MIXER                 name 'Audio lineout'                                            name 'Audio lineout'                 value false                                   |                 value true                 comment {                                                       comment {                         access 'read write'                                             access 'read write'                         type BOOLEAN                                                    type BOOLEAN                         count 1                                                         count 1                 }                                                               }         }                                                               } Step 2) Change the /etc/asound.conf file
     
    As you might or might not be aware, the default /etc/asound.conf file looks something like this:
     
    pcm.!default {     type hw     card 1 } ctl.!default {     type hw     card 1 } All it is configured to do is give applications direct access to the hardware audio device, and pump the sound either out to the analogue line-out ('card 0') or via HDMI ('card 1'). Pretty basic, but does the job.   However, what I wanted was two things: Software mixing before the resulting PCM/Sound is sent to the hardware audio device - This enables me to listen to Internet Radio and Youtube at the same time... Simultaneous Output to both HDMI and analog line-out. If you want only (1) above, and only via HDMI, then the /etc/asound.conf file is this:
    pcm.!default {   type plug   slave.pcm "dmixer" } pcm.dmixer  {   type dmix   ipc_key 1024   slave {     pcm "hw:1,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.dmixer {   type hw   card 0 } ctl.!default {     type hw     card 0 } If you want (1) and (2) (which of course you do), then the /etc/asound.conf file is this:
    # Thanks to: http://alsa.opensrc.org/Asoundrc#Dupe_output_to_multiple_cards #            https://sourceforge.net/p/alsa/mailman/message/33476395/ # Check that a MUTE doesn't exist on the Audio Line Out for Orange PI PC # or you'll get no sound other than via HDMI pcm.!default {    type plug    slave.pcm "duplicate" } ctl.!default {     type hw     card 0 } # Create the Software Mixer for HDMI and then link to hardware pcm.hdmi-dmixer  {   type dmix   ipc_key 1024   slave {     #pcm "hw:0,0"    # pcm "duplicate"     pcm "hdmi-hw" #    pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.hdmi-dmixer {   type hw   card 0 } # Create the Software Mixer for Analogue Out and then link to hardware pcm.analog-dmixer  {   type dmix   ipc_key 2048   slave {     #pcm "hw:0,0"    # pcm "duplicate"  #   pcm "hdmi-hw"     pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.analog-dmixer {   type hw   card 0 } # Route the audio requests to both hardware devices via the mixer. # For some reason we can't have one mixer and then route to two hardware # devices (would be more efficient). pcm.duplicate {     type route     slave.pcm {         type multi         slaves {             a { pcm "analog-dmixer" channels 2 }             h { pcm "hdmi-dmixer" channels 2 }         }         bindings [             { slave a channel 0 }             { slave a channel 1 }             { slave h channel 0 }             { slave h channel 1 }         ]     }     ttable [         [ 1 0 1 0 ]         [ 0 1 0 1 ]     ] } ctl.duplicate {         type hw;         card 0; } # Physical Output Device Mappings - Analogue and HDMI for Orange PI PC pcm.analog-hw {     type hw     card 0 } pcm.hdmi-hw {     type hw     card 1 }    
    There you have it. The only downside is that CPU usage for playing music will increase a bit as ALSA will essentially route inputs from applications to two Software Mixers, which are connected to the HDMI and Analog Line-Out hardware devices separately. For some reason you can't have a single Software Mixer route to two hardware devices (or I couldn't get it to work), but whatever. We're talking 20% CPU usage vs. 10% on one core, to play music.      
  10. Like
    AnonymousPi got a reaction from gregvp in Configuring Orange PI PC for analogue Line-Out jack audio output (and Simultaneous HDMI output with Software Mixing)   
    Perform 'Step 1' per my guide above, then copy-paste the /etc/asound.conf file to be:
    pcm.!default {   type plug   slave.pcm "dmixer" } pcm.dmixer  {   type dmix   ipc_key 1024   slave {     pcm "hw:0,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.dmixer {   type hw   card 0 } ctl.!default {     type hw     card 0 } The hint on what to do was in my comment within the suggested asound.conf in my original post:
    # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output
  11. Like
    AnonymousPi got a reaction from Igor in Configuring Orange PI PC for analogue Line-Out jack audio output (and Simultaneous HDMI output with Software Mixing)   
    Hi All,
     
    After I accomplished my IR Red Key Rick Rolling experiment the other day with much success, and from general end-luser use with Armbian, there were two things which irritated me, which are namely due to the default ALSA configuration that comes with stock Debian and that Armbian inherits. These were:
     
    Update: 11 September 2017. This guide will not work for newer Armbiam (Debian) installations which comes with Pulseaudio by default. If you really want what this tutorial provides, you will need to uninstall pulseaudio first: sudo apt-get remove pulseaudio
     
    1) You can't have simultaneous applications using an Audio device. So, how about if I want to stream Internet Radio with 'Radio Tray' but also get system alert sounds, or anything else? Out of luck, you'll get (for example):
    [ao/alsa] Playback open error: Device or resource busy 2) I want to actually have audio going out of the 3.5mm jack (don't really care about video out), better still if it's the same/simultaneous to what is going out via. HDMI. That means if I have a HDMI TV connected then I can get the sound from the TV, if I don't, then I can just use the 3.5mm jack (i.e. If I'm using my Pi to play Rick Astley headless/without a TV). No need to keep editing /etc/asound.conf every time.
     

     
    Solution?
     
    Step 1) Fix the mute on the analog Line-Out in alsamixer (for a start)
     
    There's a lot of noise out there about people not being able to get any sound our of the analog Line-Out jack even when having changed /etc/asound.conf. The reason for this is likely due to a mute by default on the analog audio line-out (i.e. the 3.5mm headphone jack) in alsa that you would unlikely to be aware of. I only found this out thanks to a comment here, otherwise I would have thrown by Pi PC out the window today.
     
    So to fix, you need to type in the console:
    sudo alsamixer Then F6 select the 'audiocodec', then tap the right arrow key to select the 'Audio lineout [Off]' item.
     

     
    Press 'm' and you'll get the green 'OO', which means it's now active.
     

     
    Exit alsamixer, and when you're back at the console type:
    sudo alsactl store 0 ... to store you mixer settings.
     
    For your information, the mixer settings are stored to the file:
    /var/lib/alsa/asound.state  ... and if you do a diff of this file after having made the changes in alsamixer, this is what is changed in the alsa asound.state file:
           control.9 {                                                     control.9 {                 iface MIXER                                                     iface MIXER                 name 'Audio lineout'                                            name 'Audio lineout'                 value false                                   |                 value true                 comment {                                                       comment {                         access 'read write'                                             access 'read write'                         type BOOLEAN                                                    type BOOLEAN                         count 1                                                         count 1                 }                                                               }         }                                                               } Step 2) Change the /etc/asound.conf file
     
    As you might or might not be aware, the default /etc/asound.conf file looks something like this:
     
    pcm.!default {     type hw     card 1 } ctl.!default {     type hw     card 1 } All it is configured to do is give applications direct access to the hardware audio device, and pump the sound either out to the analogue line-out ('card 0') or via HDMI ('card 1'). Pretty basic, but does the job.   However, what I wanted was two things: Software mixing before the resulting PCM/Sound is sent to the hardware audio device - This enables me to listen to Internet Radio and Youtube at the same time... Simultaneous Output to both HDMI and analog line-out. If you want only (1) above, and only via HDMI, then the /etc/asound.conf file is this:
    pcm.!default {   type plug   slave.pcm "dmixer" } pcm.dmixer  {   type dmix   ipc_key 1024   slave {     pcm "hw:1,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.dmixer {   type hw   card 0 } ctl.!default {     type hw     card 0 } If you want (1) and (2) (which of course you do), then the /etc/asound.conf file is this:
    # Thanks to: http://alsa.opensrc.org/Asoundrc#Dupe_output_to_multiple_cards #            https://sourceforge.net/p/alsa/mailman/message/33476395/ # Check that a MUTE doesn't exist on the Audio Line Out for Orange PI PC # or you'll get no sound other than via HDMI pcm.!default {    type plug    slave.pcm "duplicate" } ctl.!default {     type hw     card 0 } # Create the Software Mixer for HDMI and then link to hardware pcm.hdmi-dmixer  {   type dmix   ipc_key 1024   slave {     #pcm "hw:0,0"    # pcm "duplicate"     pcm "hdmi-hw" #    pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.hdmi-dmixer {   type hw   card 0 } # Create the Software Mixer for Analogue Out and then link to hardware pcm.analog-dmixer  {   type dmix   ipc_key 2048   slave {     #pcm "hw:0,0"    # pcm "duplicate"  #   pcm "hdmi-hw"     pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.analog-dmixer {   type hw   card 0 } # Route the audio requests to both hardware devices via the mixer. # For some reason we can't have one mixer and then route to two hardware # devices (would be more efficient). pcm.duplicate {     type route     slave.pcm {         type multi         slaves {             a { pcm "analog-dmixer" channels 2 }             h { pcm "hdmi-dmixer" channels 2 }         }         bindings [             { slave a channel 0 }             { slave a channel 1 }             { slave h channel 0 }             { slave h channel 1 }         ]     }     ttable [         [ 1 0 1 0 ]         [ 0 1 0 1 ]     ] } ctl.duplicate {         type hw;         card 0; } # Physical Output Device Mappings - Analogue and HDMI for Orange PI PC pcm.analog-hw {     type hw     card 0 } pcm.hdmi-hw {     type hw     card 1 }    
    There you have it. The only downside is that CPU usage for playing music will increase a bit as ALSA will essentially route inputs from applications to two Software Mixers, which are connected to the HDMI and Analog Line-Out hardware devices separately. For some reason you can't have a single Software Mixer route to two hardware devices (or I couldn't get it to work), but whatever. We're talking 20% CPU usage vs. 10% on one core, to play music.      
  12. Like
    AnonymousPi got a reaction from bozden in Using 16x2 ('1602') LCD with I2C connector with Orange Pi PC   
    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:
     

  13. Like
    AnonymousPi got a reaction from gungsukma in Using 16x2 ('1602') LCD with I2C connector with Orange Pi PC   
    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:
     

  14. Like
    AnonymousPi got a reaction from kris777 in Using 16x2 ('1602') LCD with I2C connector with Orange Pi PC   
    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:
     

  15. Like
    AnonymousPi got a reaction from gnasch in Using 16x2 ('1602') LCD with I2C connector with Orange Pi PC   
    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:
     

  16. Like
    AnonymousPi got a reaction from tkaiser in Using 16x2 ('1602') LCD with I2C connector with Orange Pi PC   
    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:
     

  17. Like
    AnonymousPi got a reaction from kris777 in Configuring Orange PI PC to receive IR/InfraRed   
    Note: Guide Updated May 2017, as I realise that /dev/input/event3 may not always be the IR receiver device on your armbian installation.
     
    Hi All,
     
    I recently bought an Orange PI PC and the best thing I ever did was install Armbian straight away (and donate). Now that I have a bit of spare time, I wanted to configure my Orange PI PC to do something ridiculous like play Rick Ashley 'Never going to give you up' upon pressing the 'red button' on some generic Chinese IR remote for an LED light strip I have in my living room.
     
    Thanks to Armbian, most of the pieces are in place (such as the SunXI IR package) with the distribution, you just need to glue it all together.
     
    However there are few configuration issues with the default Armbian install on the Orange PI PC that need to be adjusted, otherwise you'll encounter infuriating issues such as:
    No IR device existing or being detected (root cause: sunxi-cir module not loaded) No LIRC 'irw' output even after successfully using irrecord (root cause: DRIVER=devinput doesn't work, though it could be my remote), like this poor sod was experiencing.  
    I should also note that this guide on the terrible Orange PI forums, helped me with my issues.
     
    Step 1) Adjust /etc/lirc/hardware.conf
     
    Updated: This guide was originally written for Armbian based on Debian 'Jessie'. The latest Armbian (as at September 2017) is now based on Ubuntu Xenial. This introduces a new lirc package which yet again comes with a broken hardware.conf
     
    For Ubuntu Xenial (September 2017):
     
    The default hardware.conf that comes with Armbian is broken. It's assigning the 'remote' and 'transmitter' to the same device, this breaks everything. Ensure the TRANSMITTER_MODULES="" and TRANSMITTER_DEVICE = ""
    # /etc/lirc/hardware.conf # #Chosen Remote Control REMOTE="None" REMOTE_MODULES="sunxi_cir" REMOTE_DRIVER="default" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" # FYI - /run/lirc/lircd will probably be the socket that the system uses REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS="" #Chosen IR Transmitter TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="/dev/null" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS="" #Disable kernel support. #Typically, lirc will disable in-kernel support for ir devices in order to #handle them internally. Set to false to prevent lirc from disabling this #in-kernel support. #DISABLE_KERNEL_SUPPORT="true" #Enable lircd START_LIRCD="true" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false" #Try to load appropriate kernel modules LOAD_MODULES="true" # Default configuration files for your hardware if any LIRCMD_CONF="" #Forcing noninteractive reconfiguration #If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD=""  
    For Debian Jessie (~year 2016):
     
    By default Armbian doesn't have the suxi-cir module enabled at boot-up, but it is available, so you will need to edit hardware.conf to enable this, as well as correct the DRIVER= line and the DEVICE= line, as the defaults in there are WRONG.
     
    Also I suggest commenting out Igor's code in the top five lines. A hardware.conf that works:
    # Cubietruck automatic lirc device detection by Igor Pecovnik #str=$(cat /proc/bus/input/devices | grep "H: Handlers=sysrq rfkill kbd event" | awk '{print $(NF)}') #sed -i 's/DEVICE="\/dev\/input.*/DEVICE="\/dev\/input\/'$str'"/g' /etc/lirc/hardware.conf # /etc/lirc/hardware.conf # # Arguments which will be used when launching lircd LIRCD_ARGS="" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD=false #Don't start irexec, even if a good config file seems to exist. #START_IREXEC=false #Try to load appropriate kernel modules LOAD_MODULES=true # Run "lircd --driver=help" for a list of supported drivers. # 'devinput' driver on Orange PI PC causes NO EVENTS TO OCCUR # via irw for some reason. DRIVER="default" # usually /dev/lirc0 is the correct setting for systems using udev DEVICE="/dev/lirc0" MODULES="sunxi-cir" # Default configuration files for your hardware if any LIRCD_CONF="" LIRCMD_CONF="" Step 2) Restart lircd service
      As lirc is actually already running and installed in Armbian, do the following:
     
    root@orangepipc:/etc# /etc/init.d/lirc stop root@orangepipc:/etc# /etc/init.d/lirc start To reboot the service. 
     
    Then perform an 'lsmod' to see if it loaded the sunxi_cir module (because otherwise nothing will work):
      user@orangepipc:~$ lsmod Module                  Size  Used by mali_drm                2732  1 drm                   178255  2 mali_drm mali                  123208  0 ump                    29379  3 mali sunxi_cir               1601  0 8189es               1076034  0   Step 3) Find out what '/dev/input/eventX' device is your IR receiver   If you do a: ls /dev/input/event* You will most likely get a bunch of possible event devices to choose from, for example:
    anonymouspi@orangepipc:~$ ls /dev/input/event* /dev/input/event0 /dev/input/event2 /dev/input/event4 /dev/input/event1 /dev/input/event3 /dev/input/event5 For my installation, /dev/input/event3 is the IR receiver, but if you have other devices installed (i.e. USB cameras, keyboards etc.) then the number could be different. For example, executing 'evtest /dev/input/event3' reveals:
    Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" A device name of 'sunxi-ir' means that we are using the right device for the purposes of evtest
        Step 4) Do a quick test with with 'evtest' (OrangePI PC armbian seems to use /dev/input/event3 for IR input )   Armbian has the 'evtest' program installed, point the IR remote (in my case a  LED colour remote) at your Orange PI PC and as root 'evtest /dev/input/event3'.   root@orangepipc:/etc# evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" Supported events:   Event type 0 (EV_SYN)   Event type 1 (EV_KEY)     Event code 152 (KEY_SCREENLOCK)   Event type 4 (EV_MSC)     Event code 4 (MSC_SCAN) Key repeat handling:   Repeat type 20 (EV_REP)     Repeat code 0 (REP_DELAY)       Value    500     Repeat code 1 (REP_PERIOD)       Value    125 Properties: Testing ... (interrupt to exit)  
    Pressing the remote reveals events like:
    Testing ... (interrupt to exit) Event: time 1472917554.113967, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 Event: time 1472917554.113981, -------------- EV_SYN ------------ Event: time 1472917554.464390, type 4 (EV_MSC), code 4 (MSC_SCAN), value 59 Event: time 1472917554.464398, -------------- EV_SYN ------------ Event: time 1472917554.842832, type 4 (EV_MSC), code 4 (MSC_SCAN), value 45 Event: time 1472917554.842839, -------------- EV_SYN ------------ Event: time 1472917555.345584, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 That was the red, green, blue and white buttons being pressed. This is a good news.
     
     
    Step 5) Configure lirc to map IR input to key presses or events.
     
    Again, Armbian has irrecord installed (great work Igor), but given I'm re-using this remote to configure the output of a LED strip I have, I'll need to map the IR data sent, to something more meaningful. In other use-cases this isn't generally required as lircs provides a database of media remotes which is pre-mapped to Linux commands/keyboard keys.
     
    There's plenty of information on how to use irrecord, command I used was:
    /etc/init.d/lirc stop ...to first stop the service, then:
    irrecord -H default -d /dev/lirc0 /etc/lirc/lircd.conf ... to record my remote and bind to 'keys'.
     
     
    Step 6) Test with irw
     
    Now that I recorded my configuration file with irrecord:
    /etc/init.d/lirc start .. to start lird service again
     
    then type 'irw' and check that the key mapping works when I point the remote at the Orange PI PC and press a button:
    root@orangepipc:/etc# irw 0000000000ff1ae5 00 KEY_R /etc/lirc/lircd.conf 0000000000ff1ae5 01 KEY_R /etc/lirc/lircd.conf 0000000000ff9a65 00 KEY_G /etc/lirc/lircd.conf 0000000000ff9a65 01 KEY_G /etc/lirc/lircd.conf 0000000000ffa25d 00 KEY_B /etc/lirc/lircd.conf 0000000000ffa25d 01 KEY_B /etc/lirc/lircd.conf 0000000000ff22dd 00 KEY_W /etc/lirc/lircd.conf 0000000000ff22dd 01 KEY_W /etc/lirc/lircd.conf Hoo Ray!
      Step 7) Create a /etc/lirc/lircrc file to run commands
     
    sudo vi /etc/lirc/lircrc I'd actually call mpv here and call the player:
    # http://www.lirc.org/html/configure.html begin    button = KEY_R    prog = irexec    config = mpv  /home/root/Rick\\ Astley\\ -\\ Never\\ Gonna\\ Give\\ You\\ Up.m4a & echo "COMMENT RICK ROLLING" & end begin    button = KEY_W    prog = irexec    config = killall mpv & echo "SADFACE!" & end begin    button = KEY_B    prog = irexec    config = mpv http://sj256.hnux.com & end   You could also create a file for each user of the system if you want, eg: /root/.lircrc, /home/userXXX/.lircrc However if you do this, you will need to start the irexec service manually. If you have a /etc/lirc/lircrc file, the irexec service will start automatically at boot - this service is what actually converts the key press to the command.     So there you go, Rickrolling with a simple press of the red (KEY_R) button :-)  
     
     
    Additional References:
    [Guide] Android + InfraRed (IR) + Kodi 
    How to setup Remote Control for Linux
  18. Like
    AnonymousPi got a reaction from mss in Configuring Orange PI PC for analogue Line-Out jack audio output (and Simultaneous HDMI output with Software Mixing)   
    Hi All,
     
    After I accomplished my IR Red Key Rick Rolling experiment the other day with much success, and from general end-luser use with Armbian, there were two things which irritated me, which are namely due to the default ALSA configuration that comes with stock Debian and that Armbian inherits. These were:
     
    Update: 11 September 2017. This guide will not work for newer Armbiam (Debian) installations which comes with Pulseaudio by default. If you really want what this tutorial provides, you will need to uninstall pulseaudio first: sudo apt-get remove pulseaudio
     
    1) You can't have simultaneous applications using an Audio device. So, how about if I want to stream Internet Radio with 'Radio Tray' but also get system alert sounds, or anything else? Out of luck, you'll get (for example):
    [ao/alsa] Playback open error: Device or resource busy 2) I want to actually have audio going out of the 3.5mm jack (don't really care about video out), better still if it's the same/simultaneous to what is going out via. HDMI. That means if I have a HDMI TV connected then I can get the sound from the TV, if I don't, then I can just use the 3.5mm jack (i.e. If I'm using my Pi to play Rick Astley headless/without a TV). No need to keep editing /etc/asound.conf every time.
     

     
    Solution?
     
    Step 1) Fix the mute on the analog Line-Out in alsamixer (for a start)
     
    There's a lot of noise out there about people not being able to get any sound our of the analog Line-Out jack even when having changed /etc/asound.conf. The reason for this is likely due to a mute by default on the analog audio line-out (i.e. the 3.5mm headphone jack) in alsa that you would unlikely to be aware of. I only found this out thanks to a comment here, otherwise I would have thrown by Pi PC out the window today.
     
    So to fix, you need to type in the console:
    sudo alsamixer Then F6 select the 'audiocodec', then tap the right arrow key to select the 'Audio lineout [Off]' item.
     

     
    Press 'm' and you'll get the green 'OO', which means it's now active.
     

     
    Exit alsamixer, and when you're back at the console type:
    sudo alsactl store 0 ... to store you mixer settings.
     
    For your information, the mixer settings are stored to the file:
    /var/lib/alsa/asound.state  ... and if you do a diff of this file after having made the changes in alsamixer, this is what is changed in the alsa asound.state file:
           control.9 {                                                     control.9 {                 iface MIXER                                                     iface MIXER                 name 'Audio lineout'                                            name 'Audio lineout'                 value false                                   |                 value true                 comment {                                                       comment {                         access 'read write'                                             access 'read write'                         type BOOLEAN                                                    type BOOLEAN                         count 1                                                         count 1                 }                                                               }         }                                                               } Step 2) Change the /etc/asound.conf file
     
    As you might or might not be aware, the default /etc/asound.conf file looks something like this:
     
    pcm.!default {     type hw     card 1 } ctl.!default {     type hw     card 1 } All it is configured to do is give applications direct access to the hardware audio device, and pump the sound either out to the analogue line-out ('card 0') or via HDMI ('card 1'). Pretty basic, but does the job.   However, what I wanted was two things: Software mixing before the resulting PCM/Sound is sent to the hardware audio device - This enables me to listen to Internet Radio and Youtube at the same time... Simultaneous Output to both HDMI and analog line-out. If you want only (1) above, and only via HDMI, then the /etc/asound.conf file is this:
    pcm.!default {   type plug   slave.pcm "dmixer" } pcm.dmixer  {   type dmix   ipc_key 1024   slave {     pcm "hw:1,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.dmixer {   type hw   card 0 } ctl.!default {     type hw     card 0 } If you want (1) and (2) (which of course you do), then the /etc/asound.conf file is this:
    # Thanks to: http://alsa.opensrc.org/Asoundrc#Dupe_output_to_multiple_cards #            https://sourceforge.net/p/alsa/mailman/message/33476395/ # Check that a MUTE doesn't exist on the Audio Line Out for Orange PI PC # or you'll get no sound other than via HDMI pcm.!default {    type plug    slave.pcm "duplicate" } ctl.!default {     type hw     card 0 } # Create the Software Mixer for HDMI and then link to hardware pcm.hdmi-dmixer  {   type dmix   ipc_key 1024   slave {     #pcm "hw:0,0"    # pcm "duplicate"     pcm "hdmi-hw" #    pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.hdmi-dmixer {   type hw   card 0 } # Create the Software Mixer for Analogue Out and then link to hardware pcm.analog-dmixer  {   type dmix   ipc_key 2048   slave {     #pcm "hw:0,0"    # pcm "duplicate"  #   pcm "hdmi-hw"     pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.analog-dmixer {   type hw   card 0 } # Route the audio requests to both hardware devices via the mixer. # For some reason we can't have one mixer and then route to two hardware # devices (would be more efficient). pcm.duplicate {     type route     slave.pcm {         type multi         slaves {             a { pcm "analog-dmixer" channels 2 }             h { pcm "hdmi-dmixer" channels 2 }         }         bindings [             { slave a channel 0 }             { slave a channel 1 }             { slave h channel 0 }             { slave h channel 1 }         ]     }     ttable [         [ 1 0 1 0 ]         [ 0 1 0 1 ]     ] } ctl.duplicate {         type hw;         card 0; } # Physical Output Device Mappings - Analogue and HDMI for Orange PI PC pcm.analog-hw {     type hw     card 0 } pcm.hdmi-hw {     type hw     card 1 }    
    There you have it. The only downside is that CPU usage for playing music will increase a bit as ALSA will essentially route inputs from applications to two Software Mixers, which are connected to the HDMI and Analog Line-Out hardware devices separately. For some reason you can't have a single Software Mixer route to two hardware devices (or I couldn't get it to work), but whatever. We're talking 20% CPU usage vs. 10% on one core, to play music.      
  19. Like
    AnonymousPi got a reaction from manuti in Configuring Orange PI PC for analogue Line-Out jack audio output (and Simultaneous HDMI output with Software Mixing)   
    Perform 'Step 1' per my guide above, then copy-paste the /etc/asound.conf file to be:
    pcm.!default {   type plug   slave.pcm "dmixer" } pcm.dmixer  {   type dmix   ipc_key 1024   slave {     pcm "hw:0,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.dmixer {   type hw   card 0 } ctl.!default {     type hw     card 0 } The hint on what to do was in my comment within the suggested asound.conf in my original post:
    # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output
  20. Like
    AnonymousPi got a reaction from Davey Darko in Configuring Orange PI PC to receive IR/InfraRed   
    Note: Guide Updated May 2017, as I realise that /dev/input/event3 may not always be the IR receiver device on your armbian installation.
     
    Hi All,
     
    I recently bought an Orange PI PC and the best thing I ever did was install Armbian straight away (and donate). Now that I have a bit of spare time, I wanted to configure my Orange PI PC to do something ridiculous like play Rick Ashley 'Never going to give you up' upon pressing the 'red button' on some generic Chinese IR remote for an LED light strip I have in my living room.
     
    Thanks to Armbian, most of the pieces are in place (such as the SunXI IR package) with the distribution, you just need to glue it all together.
     
    However there are few configuration issues with the default Armbian install on the Orange PI PC that need to be adjusted, otherwise you'll encounter infuriating issues such as:
    No IR device existing or being detected (root cause: sunxi-cir module not loaded) No LIRC 'irw' output even after successfully using irrecord (root cause: DRIVER=devinput doesn't work, though it could be my remote), like this poor sod was experiencing.  
    I should also note that this guide on the terrible Orange PI forums, helped me with my issues.
     
    Step 1) Adjust /etc/lirc/hardware.conf
     
    Updated: This guide was originally written for Armbian based on Debian 'Jessie'. The latest Armbian (as at September 2017) is now based on Ubuntu Xenial. This introduces a new lirc package which yet again comes with a broken hardware.conf
     
    For Ubuntu Xenial (September 2017):
     
    The default hardware.conf that comes with Armbian is broken. It's assigning the 'remote' and 'transmitter' to the same device, this breaks everything. Ensure the TRANSMITTER_MODULES="" and TRANSMITTER_DEVICE = ""
    # /etc/lirc/hardware.conf # #Chosen Remote Control REMOTE="None" REMOTE_MODULES="sunxi_cir" REMOTE_DRIVER="default" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" # FYI - /run/lirc/lircd will probably be the socket that the system uses REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS="" #Chosen IR Transmitter TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="/dev/null" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS="" #Disable kernel support. #Typically, lirc will disable in-kernel support for ir devices in order to #handle them internally. Set to false to prevent lirc from disabling this #in-kernel support. #DISABLE_KERNEL_SUPPORT="true" #Enable lircd START_LIRCD="true" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false" #Try to load appropriate kernel modules LOAD_MODULES="true" # Default configuration files for your hardware if any LIRCMD_CONF="" #Forcing noninteractive reconfiguration #If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD=""  
    For Debian Jessie (~year 2016):
     
    By default Armbian doesn't have the suxi-cir module enabled at boot-up, but it is available, so you will need to edit hardware.conf to enable this, as well as correct the DRIVER= line and the DEVICE= line, as the defaults in there are WRONG.
     
    Also I suggest commenting out Igor's code in the top five lines. A hardware.conf that works:
    # Cubietruck automatic lirc device detection by Igor Pecovnik #str=$(cat /proc/bus/input/devices | grep "H: Handlers=sysrq rfkill kbd event" | awk '{print $(NF)}') #sed -i 's/DEVICE="\/dev\/input.*/DEVICE="\/dev\/input\/'$str'"/g' /etc/lirc/hardware.conf # /etc/lirc/hardware.conf # # Arguments which will be used when launching lircd LIRCD_ARGS="" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD=false #Don't start irexec, even if a good config file seems to exist. #START_IREXEC=false #Try to load appropriate kernel modules LOAD_MODULES=true # Run "lircd --driver=help" for a list of supported drivers. # 'devinput' driver on Orange PI PC causes NO EVENTS TO OCCUR # via irw for some reason. DRIVER="default" # usually /dev/lirc0 is the correct setting for systems using udev DEVICE="/dev/lirc0" MODULES="sunxi-cir" # Default configuration files for your hardware if any LIRCD_CONF="" LIRCMD_CONF="" Step 2) Restart lircd service
      As lirc is actually already running and installed in Armbian, do the following:
     
    root@orangepipc:/etc# /etc/init.d/lirc stop root@orangepipc:/etc# /etc/init.d/lirc start To reboot the service. 
     
    Then perform an 'lsmod' to see if it loaded the sunxi_cir module (because otherwise nothing will work):
      user@orangepipc:~$ lsmod Module                  Size  Used by mali_drm                2732  1 drm                   178255  2 mali_drm mali                  123208  0 ump                    29379  3 mali sunxi_cir               1601  0 8189es               1076034  0   Step 3) Find out what '/dev/input/eventX' device is your IR receiver   If you do a: ls /dev/input/event* You will most likely get a bunch of possible event devices to choose from, for example:
    anonymouspi@orangepipc:~$ ls /dev/input/event* /dev/input/event0 /dev/input/event2 /dev/input/event4 /dev/input/event1 /dev/input/event3 /dev/input/event5 For my installation, /dev/input/event3 is the IR receiver, but if you have other devices installed (i.e. USB cameras, keyboards etc.) then the number could be different. For example, executing 'evtest /dev/input/event3' reveals:
    Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" A device name of 'sunxi-ir' means that we are using the right device for the purposes of evtest
        Step 4) Do a quick test with with 'evtest' (OrangePI PC armbian seems to use /dev/input/event3 for IR input )   Armbian has the 'evtest' program installed, point the IR remote (in my case a  LED colour remote) at your Orange PI PC and as root 'evtest /dev/input/event3'.   root@orangepipc:/etc# evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" Supported events:   Event type 0 (EV_SYN)   Event type 1 (EV_KEY)     Event code 152 (KEY_SCREENLOCK)   Event type 4 (EV_MSC)     Event code 4 (MSC_SCAN) Key repeat handling:   Repeat type 20 (EV_REP)     Repeat code 0 (REP_DELAY)       Value    500     Repeat code 1 (REP_PERIOD)       Value    125 Properties: Testing ... (interrupt to exit)  
    Pressing the remote reveals events like:
    Testing ... (interrupt to exit) Event: time 1472917554.113967, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 Event: time 1472917554.113981, -------------- EV_SYN ------------ Event: time 1472917554.464390, type 4 (EV_MSC), code 4 (MSC_SCAN), value 59 Event: time 1472917554.464398, -------------- EV_SYN ------------ Event: time 1472917554.842832, type 4 (EV_MSC), code 4 (MSC_SCAN), value 45 Event: time 1472917554.842839, -------------- EV_SYN ------------ Event: time 1472917555.345584, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 That was the red, green, blue and white buttons being pressed. This is a good news.
     
     
    Step 5) Configure lirc to map IR input to key presses or events.
     
    Again, Armbian has irrecord installed (great work Igor), but given I'm re-using this remote to configure the output of a LED strip I have, I'll need to map the IR data sent, to something more meaningful. In other use-cases this isn't generally required as lircs provides a database of media remotes which is pre-mapped to Linux commands/keyboard keys.
     
    There's plenty of information on how to use irrecord, command I used was:
    /etc/init.d/lirc stop ...to first stop the service, then:
    irrecord -H default -d /dev/lirc0 /etc/lirc/lircd.conf ... to record my remote and bind to 'keys'.
     
     
    Step 6) Test with irw
     
    Now that I recorded my configuration file with irrecord:
    /etc/init.d/lirc start .. to start lird service again
     
    then type 'irw' and check that the key mapping works when I point the remote at the Orange PI PC and press a button:
    root@orangepipc:/etc# irw 0000000000ff1ae5 00 KEY_R /etc/lirc/lircd.conf 0000000000ff1ae5 01 KEY_R /etc/lirc/lircd.conf 0000000000ff9a65 00 KEY_G /etc/lirc/lircd.conf 0000000000ff9a65 01 KEY_G /etc/lirc/lircd.conf 0000000000ffa25d 00 KEY_B /etc/lirc/lircd.conf 0000000000ffa25d 01 KEY_B /etc/lirc/lircd.conf 0000000000ff22dd 00 KEY_W /etc/lirc/lircd.conf 0000000000ff22dd 01 KEY_W /etc/lirc/lircd.conf Hoo Ray!
      Step 7) Create a /etc/lirc/lircrc file to run commands
     
    sudo vi /etc/lirc/lircrc I'd actually call mpv here and call the player:
    # http://www.lirc.org/html/configure.html begin    button = KEY_R    prog = irexec    config = mpv  /home/root/Rick\\ Astley\\ -\\ Never\\ Gonna\\ Give\\ You\\ Up.m4a & echo "COMMENT RICK ROLLING" & end begin    button = KEY_W    prog = irexec    config = killall mpv & echo "SADFACE!" & end begin    button = KEY_B    prog = irexec    config = mpv http://sj256.hnux.com & end   You could also create a file for each user of the system if you want, eg: /root/.lircrc, /home/userXXX/.lircrc However if you do this, you will need to start the irexec service manually. If you have a /etc/lirc/lircrc file, the irexec service will start automatically at boot - this service is what actually converts the key press to the command.     So there you go, Rickrolling with a simple press of the red (KEY_R) button :-)  
     
     
    Additional References:
    [Guide] Android + InfraRed (IR) + Kodi 
    How to setup Remote Control for Linux
  21. Like
    AnonymousPi got a reaction from PoV in Configuring Orange PI PC to receive IR/InfraRed   
    Note: Guide Updated May 2017, as I realise that /dev/input/event3 may not always be the IR receiver device on your armbian installation.
     
    Hi All,
     
    I recently bought an Orange PI PC and the best thing I ever did was install Armbian straight away (and donate). Now that I have a bit of spare time, I wanted to configure my Orange PI PC to do something ridiculous like play Rick Ashley 'Never going to give you up' upon pressing the 'red button' on some generic Chinese IR remote for an LED light strip I have in my living room.
     
    Thanks to Armbian, most of the pieces are in place (such as the SunXI IR package) with the distribution, you just need to glue it all together.
     
    However there are few configuration issues with the default Armbian install on the Orange PI PC that need to be adjusted, otherwise you'll encounter infuriating issues such as:
    No IR device existing or being detected (root cause: sunxi-cir module not loaded) No LIRC 'irw' output even after successfully using irrecord (root cause: DRIVER=devinput doesn't work, though it could be my remote), like this poor sod was experiencing.  
    I should also note that this guide on the terrible Orange PI forums, helped me with my issues.
     
    Step 1) Adjust /etc/lirc/hardware.conf
     
    Updated: This guide was originally written for Armbian based on Debian 'Jessie'. The latest Armbian (as at September 2017) is now based on Ubuntu Xenial. This introduces a new lirc package which yet again comes with a broken hardware.conf
     
    For Ubuntu Xenial (September 2017):
     
    The default hardware.conf that comes with Armbian is broken. It's assigning the 'remote' and 'transmitter' to the same device, this breaks everything. Ensure the TRANSMITTER_MODULES="" and TRANSMITTER_DEVICE = ""
    # /etc/lirc/hardware.conf # #Chosen Remote Control REMOTE="None" REMOTE_MODULES="sunxi_cir" REMOTE_DRIVER="default" REMOTE_DEVICE="/dev/lirc0" REMOTE_SOCKET="" # FYI - /run/lirc/lircd will probably be the socket that the system uses REMOTE_LIRCD_CONF="" REMOTE_LIRCD_ARGS="" #Chosen IR Transmitter TRANSMITTER="None" TRANSMITTER_MODULES="" TRANSMITTER_DRIVER="" TRANSMITTER_DEVICE="/dev/null" TRANSMITTER_SOCKET="" TRANSMITTER_LIRCD_CONF="" TRANSMITTER_LIRCD_ARGS="" #Disable kernel support. #Typically, lirc will disable in-kernel support for ir devices in order to #handle them internally. Set to false to prevent lirc from disabling this #in-kernel support. #DISABLE_KERNEL_SUPPORT="true" #Enable lircd START_LIRCD="true" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD="false" #Try to load appropriate kernel modules LOAD_MODULES="true" # Default configuration files for your hardware if any LIRCMD_CONF="" #Forcing noninteractive reconfiguration #If lirc is to be reconfigured by an external application #that doesn't have a debconf frontend available, the noninteractive #frontend can be invoked and set to parse REMOTE and TRANSMITTER #It will then populate all other variables without any user input #If you would like to configure lirc via standard methods, be sure #to leave this set to "false" FORCE_NONINTERACTIVE_RECONFIGURATION="false" START_LIRCMD=""  
    For Debian Jessie (~year 2016):
     
    By default Armbian doesn't have the suxi-cir module enabled at boot-up, but it is available, so you will need to edit hardware.conf to enable this, as well as correct the DRIVER= line and the DEVICE= line, as the defaults in there are WRONG.
     
    Also I suggest commenting out Igor's code in the top five lines. A hardware.conf that works:
    # Cubietruck automatic lirc device detection by Igor Pecovnik #str=$(cat /proc/bus/input/devices | grep "H: Handlers=sysrq rfkill kbd event" | awk '{print $(NF)}') #sed -i 's/DEVICE="\/dev\/input.*/DEVICE="\/dev\/input\/'$str'"/g' /etc/lirc/hardware.conf # /etc/lirc/hardware.conf # # Arguments which will be used when launching lircd LIRCD_ARGS="" #Don't start lircmd even if there seems to be a good config file #START_LIRCMD=false #Don't start irexec, even if a good config file seems to exist. #START_IREXEC=false #Try to load appropriate kernel modules LOAD_MODULES=true # Run "lircd --driver=help" for a list of supported drivers. # 'devinput' driver on Orange PI PC causes NO EVENTS TO OCCUR # via irw for some reason. DRIVER="default" # usually /dev/lirc0 is the correct setting for systems using udev DEVICE="/dev/lirc0" MODULES="sunxi-cir" # Default configuration files for your hardware if any LIRCD_CONF="" LIRCMD_CONF="" Step 2) Restart lircd service
      As lirc is actually already running and installed in Armbian, do the following:
     
    root@orangepipc:/etc# /etc/init.d/lirc stop root@orangepipc:/etc# /etc/init.d/lirc start To reboot the service. 
     
    Then perform an 'lsmod' to see if it loaded the sunxi_cir module (because otherwise nothing will work):
      user@orangepipc:~$ lsmod Module                  Size  Used by mali_drm                2732  1 drm                   178255  2 mali_drm mali                  123208  0 ump                    29379  3 mali sunxi_cir               1601  0 8189es               1076034  0   Step 3) Find out what '/dev/input/eventX' device is your IR receiver   If you do a: ls /dev/input/event* You will most likely get a bunch of possible event devices to choose from, for example:
    anonymouspi@orangepipc:~$ ls /dev/input/event* /dev/input/event0 /dev/input/event2 /dev/input/event4 /dev/input/event1 /dev/input/event3 /dev/input/event5 For my installation, /dev/input/event3 is the IR receiver, but if you have other devices installed (i.e. USB cameras, keyboards etc.) then the number could be different. For example, executing 'evtest /dev/input/event3' reveals:
    Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" A device name of 'sunxi-ir' means that we are using the right device for the purposes of evtest
        Step 4) Do a quick test with with 'evtest' (OrangePI PC armbian seems to use /dev/input/event3 for IR input )   Armbian has the 'evtest' program installed, point the IR remote (in my case a  LED colour remote) at your Orange PI PC and as root 'evtest /dev/input/event3'.   root@orangepipc:/etc# evtest /dev/input/event3 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sunxi-ir" Supported events:   Event type 0 (EV_SYN)   Event type 1 (EV_KEY)     Event code 152 (KEY_SCREENLOCK)   Event type 4 (EV_MSC)     Event code 4 (MSC_SCAN) Key repeat handling:   Repeat type 20 (EV_REP)     Repeat code 0 (REP_DELAY)       Value    500     Repeat code 1 (REP_PERIOD)       Value    125 Properties: Testing ... (interrupt to exit)  
    Pressing the remote reveals events like:
    Testing ... (interrupt to exit) Event: time 1472917554.113967, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 Event: time 1472917554.113981, -------------- EV_SYN ------------ Event: time 1472917554.464390, type 4 (EV_MSC), code 4 (MSC_SCAN), value 59 Event: time 1472917554.464398, -------------- EV_SYN ------------ Event: time 1472917554.842832, type 4 (EV_MSC), code 4 (MSC_SCAN), value 45 Event: time 1472917554.842839, -------------- EV_SYN ------------ Event: time 1472917555.345584, type 4 (EV_MSC), code 4 (MSC_SCAN), value 58 That was the red, green, blue and white buttons being pressed. This is a good news.
     
     
    Step 5) Configure lirc to map IR input to key presses or events.
     
    Again, Armbian has irrecord installed (great work Igor), but given I'm re-using this remote to configure the output of a LED strip I have, I'll need to map the IR data sent, to something more meaningful. In other use-cases this isn't generally required as lircs provides a database of media remotes which is pre-mapped to Linux commands/keyboard keys.
     
    There's plenty of information on how to use irrecord, command I used was:
    /etc/init.d/lirc stop ...to first stop the service, then:
    irrecord -H default -d /dev/lirc0 /etc/lirc/lircd.conf ... to record my remote and bind to 'keys'.
     
     
    Step 6) Test with irw
     
    Now that I recorded my configuration file with irrecord:
    /etc/init.d/lirc start .. to start lird service again
     
    then type 'irw' and check that the key mapping works when I point the remote at the Orange PI PC and press a button:
    root@orangepipc:/etc# irw 0000000000ff1ae5 00 KEY_R /etc/lirc/lircd.conf 0000000000ff1ae5 01 KEY_R /etc/lirc/lircd.conf 0000000000ff9a65 00 KEY_G /etc/lirc/lircd.conf 0000000000ff9a65 01 KEY_G /etc/lirc/lircd.conf 0000000000ffa25d 00 KEY_B /etc/lirc/lircd.conf 0000000000ffa25d 01 KEY_B /etc/lirc/lircd.conf 0000000000ff22dd 00 KEY_W /etc/lirc/lircd.conf 0000000000ff22dd 01 KEY_W /etc/lirc/lircd.conf Hoo Ray!
      Step 7) Create a /etc/lirc/lircrc file to run commands
     
    sudo vi /etc/lirc/lircrc I'd actually call mpv here and call the player:
    # http://www.lirc.org/html/configure.html begin    button = KEY_R    prog = irexec    config = mpv  /home/root/Rick\\ Astley\\ -\\ Never\\ Gonna\\ Give\\ You\\ Up.m4a & echo "COMMENT RICK ROLLING" & end begin    button = KEY_W    prog = irexec    config = killall mpv & echo "SADFACE!" & end begin    button = KEY_B    prog = irexec    config = mpv http://sj256.hnux.com & end   You could also create a file for each user of the system if you want, eg: /root/.lircrc, /home/userXXX/.lircrc However if you do this, you will need to start the irexec service manually. If you have a /etc/lirc/lircrc file, the irexec service will start automatically at boot - this service is what actually converts the key press to the command.     So there you go, Rickrolling with a simple press of the red (KEY_R) button :-)  
     
     
    Additional References:
    [Guide] Android + InfraRed (IR) + Kodi 
    How to setup Remote Control for Linux
  22. Like
    AnonymousPi got a reaction from WarHawk_AVG in Thank you heaps for making Armbian!   
    Hi,
     
    Just joined to say thanks to all to those that are involved in the development of Armbian. I recently bought an Orange Pi PC after reading the internet full of people bitching about non-booting devices, HDMI issues, overheating and general crapness.
     
    Decided to buy a Orange Pi PC nonetheless, found an old crap micro SD card, burnt Armbian (the internet has made it clear to not bother with the crap on the official Orange Pi website!) onto it and the thing booted without any issues! Typing this message from it as we speak in Iceweasel!
     
    The thing only cost me 9 quid, so decided to donate what I would have wasted in cash on a Raspberry Pi 3 (which is anything but the 25 dollar SBC it seems to be advertised) as a donation to Igor and co.
     
    I just run the Orange Pi PC out of the plastic static bag it came in LOL!
     
    Once again, great work.
  23. Like
    AnonymousPi got a reaction from RagnerBG in Configuring Orange PI PC for analogue Line-Out jack audio output (and Simultaneous HDMI output with Software Mixing)   
    Hi All,
     
    After I accomplished my IR Red Key Rick Rolling experiment the other day with much success, and from general end-luser use with Armbian, there were two things which irritated me, which are namely due to the default ALSA configuration that comes with stock Debian and that Armbian inherits. These were:
     
    Update: 11 September 2017. This guide will not work for newer Armbiam (Debian) installations which comes with Pulseaudio by default. If you really want what this tutorial provides, you will need to uninstall pulseaudio first: sudo apt-get remove pulseaudio
     
    1) You can't have simultaneous applications using an Audio device. So, how about if I want to stream Internet Radio with 'Radio Tray' but also get system alert sounds, or anything else? Out of luck, you'll get (for example):
    [ao/alsa] Playback open error: Device or resource busy 2) I want to actually have audio going out of the 3.5mm jack (don't really care about video out), better still if it's the same/simultaneous to what is going out via. HDMI. That means if I have a HDMI TV connected then I can get the sound from the TV, if I don't, then I can just use the 3.5mm jack (i.e. If I'm using my Pi to play Rick Astley headless/without a TV). No need to keep editing /etc/asound.conf every time.
     

     
    Solution?
     
    Step 1) Fix the mute on the analog Line-Out in alsamixer (for a start)
     
    There's a lot of noise out there about people not being able to get any sound our of the analog Line-Out jack even when having changed /etc/asound.conf. The reason for this is likely due to a mute by default on the analog audio line-out (i.e. the 3.5mm headphone jack) in alsa that you would unlikely to be aware of. I only found this out thanks to a comment here, otherwise I would have thrown by Pi PC out the window today.
     
    So to fix, you need to type in the console:
    sudo alsamixer Then F6 select the 'audiocodec', then tap the right arrow key to select the 'Audio lineout [Off]' item.
     

     
    Press 'm' and you'll get the green 'OO', which means it's now active.
     

     
    Exit alsamixer, and when you're back at the console type:
    sudo alsactl store 0 ... to store you mixer settings.
     
    For your information, the mixer settings are stored to the file:
    /var/lib/alsa/asound.state  ... and if you do a diff of this file after having made the changes in alsamixer, this is what is changed in the alsa asound.state file:
           control.9 {                                                     control.9 {                 iface MIXER                                                     iface MIXER                 name 'Audio lineout'                                            name 'Audio lineout'                 value false                                   |                 value true                 comment {                                                       comment {                         access 'read write'                                             access 'read write'                         type BOOLEAN                                                    type BOOLEAN                         count 1                                                         count 1                 }                                                               }         }                                                               } Step 2) Change the /etc/asound.conf file
     
    As you might or might not be aware, the default /etc/asound.conf file looks something like this:
     
    pcm.!default {     type hw     card 1 } ctl.!default {     type hw     card 1 } All it is configured to do is give applications direct access to the hardware audio device, and pump the sound either out to the analogue line-out ('card 0') or via HDMI ('card 1'). Pretty basic, but does the job.   However, what I wanted was two things: Software mixing before the resulting PCM/Sound is sent to the hardware audio device - This enables me to listen to Internet Radio and Youtube at the same time... Simultaneous Output to both HDMI and analog line-out. If you want only (1) above, and only via HDMI, then the /etc/asound.conf file is this:
    pcm.!default {   type plug   slave.pcm "dmixer" } pcm.dmixer  {   type dmix   ipc_key 1024   slave {     pcm "hw:1,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.dmixer {   type hw   card 0 } ctl.!default {     type hw     card 0 } If you want (1) and (2) (which of course you do), then the /etc/asound.conf file is this:
    # Thanks to: http://alsa.opensrc.org/Asoundrc#Dupe_output_to_multiple_cards #            https://sourceforge.net/p/alsa/mailman/message/33476395/ # Check that a MUTE doesn't exist on the Audio Line Out for Orange PI PC # or you'll get no sound other than via HDMI pcm.!default {    type plug    slave.pcm "duplicate" } ctl.!default {     type hw     card 0 } # Create the Software Mixer for HDMI and then link to hardware pcm.hdmi-dmixer  {   type dmix   ipc_key 1024   slave {     #pcm "hw:0,0"    # pcm "duplicate"     pcm "hdmi-hw" #    pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.hdmi-dmixer {   type hw   card 0 } # Create the Software Mixer for Analogue Out and then link to hardware pcm.analog-dmixer  {   type dmix   ipc_key 2048   slave {     #pcm "hw:0,0"    # pcm "duplicate"  #   pcm "hdmi-hw"     pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.analog-dmixer {   type hw   card 0 } # Route the audio requests to both hardware devices via the mixer. # For some reason we can't have one mixer and then route to two hardware # devices (would be more efficient). pcm.duplicate {     type route     slave.pcm {         type multi         slaves {             a { pcm "analog-dmixer" channels 2 }             h { pcm "hdmi-dmixer" channels 2 }         }         bindings [             { slave a channel 0 }             { slave a channel 1 }             { slave h channel 0 }             { slave h channel 1 }         ]     }     ttable [         [ 1 0 1 0 ]         [ 0 1 0 1 ]     ] } ctl.duplicate {         type hw;         card 0; } # Physical Output Device Mappings - Analogue and HDMI for Orange PI PC pcm.analog-hw {     type hw     card 0 } pcm.hdmi-hw {     type hw     card 1 }    
    There you have it. The only downside is that CPU usage for playing music will increase a bit as ALSA will essentially route inputs from applications to two Software Mixers, which are connected to the HDMI and Analog Line-Out hardware devices separately. For some reason you can't have a single Software Mixer route to two hardware devices (or I couldn't get it to work), but whatever. We're talking 20% CPU usage vs. 10% on one core, to play music.      
  24. Like
    AnonymousPi got a reaction from tkaiser in Configuring Orange PI PC for analogue Line-Out jack audio output (and Simultaneous HDMI output with Software Mixing)   
    Hi All,
     
    After I accomplished my IR Red Key Rick Rolling experiment the other day with much success, and from general end-luser use with Armbian, there were two things which irritated me, which are namely due to the default ALSA configuration that comes with stock Debian and that Armbian inherits. These were:
     
    Update: 11 September 2017. This guide will not work for newer Armbiam (Debian) installations which comes with Pulseaudio by default. If you really want what this tutorial provides, you will need to uninstall pulseaudio first: sudo apt-get remove pulseaudio
     
    1) You can't have simultaneous applications using an Audio device. So, how about if I want to stream Internet Radio with 'Radio Tray' but also get system alert sounds, or anything else? Out of luck, you'll get (for example):
    [ao/alsa] Playback open error: Device or resource busy 2) I want to actually have audio going out of the 3.5mm jack (don't really care about video out), better still if it's the same/simultaneous to what is going out via. HDMI. That means if I have a HDMI TV connected then I can get the sound from the TV, if I don't, then I can just use the 3.5mm jack (i.e. If I'm using my Pi to play Rick Astley headless/without a TV). No need to keep editing /etc/asound.conf every time.
     

     
    Solution?
     
    Step 1) Fix the mute on the analog Line-Out in alsamixer (for a start)
     
    There's a lot of noise out there about people not being able to get any sound our of the analog Line-Out jack even when having changed /etc/asound.conf. The reason for this is likely due to a mute by default on the analog audio line-out (i.e. the 3.5mm headphone jack) in alsa that you would unlikely to be aware of. I only found this out thanks to a comment here, otherwise I would have thrown by Pi PC out the window today.
     
    So to fix, you need to type in the console:
    sudo alsamixer Then F6 select the 'audiocodec', then tap the right arrow key to select the 'Audio lineout [Off]' item.
     

     
    Press 'm' and you'll get the green 'OO', which means it's now active.
     

     
    Exit alsamixer, and when you're back at the console type:
    sudo alsactl store 0 ... to store you mixer settings.
     
    For your information, the mixer settings are stored to the file:
    /var/lib/alsa/asound.state  ... and if you do a diff of this file after having made the changes in alsamixer, this is what is changed in the alsa asound.state file:
           control.9 {                                                     control.9 {                 iface MIXER                                                     iface MIXER                 name 'Audio lineout'                                            name 'Audio lineout'                 value false                                   |                 value true                 comment {                                                       comment {                         access 'read write'                                             access 'read write'                         type BOOLEAN                                                    type BOOLEAN                         count 1                                                         count 1                 }                                                               }         }                                                               } Step 2) Change the /etc/asound.conf file
     
    As you might or might not be aware, the default /etc/asound.conf file looks something like this:
     
    pcm.!default {     type hw     card 1 } ctl.!default {     type hw     card 1 } All it is configured to do is give applications direct access to the hardware audio device, and pump the sound either out to the analogue line-out ('card 0') or via HDMI ('card 1'). Pretty basic, but does the job.   However, what I wanted was two things: Software mixing before the resulting PCM/Sound is sent to the hardware audio device - This enables me to listen to Internet Radio and Youtube at the same time... Simultaneous Output to both HDMI and analog line-out. If you want only (1) above, and only via HDMI, then the /etc/asound.conf file is this:
    pcm.!default {   type plug   slave.pcm "dmixer" } pcm.dmixer  {   type dmix   ipc_key 1024   slave {     pcm "hw:1,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.dmixer {   type hw   card 0 } ctl.!default {     type hw     card 0 } If you want (1) and (2) (which of course you do), then the /etc/asound.conf file is this:
    # Thanks to: http://alsa.opensrc.org/Asoundrc#Dupe_output_to_multiple_cards #            https://sourceforge.net/p/alsa/mailman/message/33476395/ # Check that a MUTE doesn't exist on the Audio Line Out for Orange PI PC # or you'll get no sound other than via HDMI pcm.!default {    type plug    slave.pcm "duplicate" } ctl.!default {     type hw     card 0 } # Create the Software Mixer for HDMI and then link to hardware pcm.hdmi-dmixer  {   type dmix   ipc_key 1024   slave {     #pcm "hw:0,0"    # pcm "duplicate"     pcm "hdmi-hw" #    pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.hdmi-dmixer {   type hw   card 0 } # Create the Software Mixer for Analogue Out and then link to hardware pcm.analog-dmixer  {   type dmix   ipc_key 2048   slave {     #pcm "hw:0,0"    # pcm "duplicate"  #   pcm "hdmi-hw"     pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.analog-dmixer {   type hw   card 0 } # Route the audio requests to both hardware devices via the mixer. # For some reason we can't have one mixer and then route to two hardware # devices (would be more efficient). pcm.duplicate {     type route     slave.pcm {         type multi         slaves {             a { pcm "analog-dmixer" channels 2 }             h { pcm "hdmi-dmixer" channels 2 }         }         bindings [             { slave a channel 0 }             { slave a channel 1 }             { slave h channel 0 }             { slave h channel 1 }         ]     }     ttable [         [ 1 0 1 0 ]         [ 0 1 0 1 ]     ] } ctl.duplicate {         type hw;         card 0; } # Physical Output Device Mappings - Analogue and HDMI for Orange PI PC pcm.analog-hw {     type hw     card 0 } pcm.hdmi-hw {     type hw     card 1 }    
    There you have it. The only downside is that CPU usage for playing music will increase a bit as ALSA will essentially route inputs from applications to two Software Mixers, which are connected to the HDMI and Analog Line-Out hardware devices separately. For some reason you can't have a single Software Mixer route to two hardware devices (or I couldn't get it to work), but whatever. We're talking 20% CPU usage vs. 10% on one core, to play music.      
  25. Like
    AnonymousPi got a reaction from gnasch in Configuring Orange PI PC for analogue Line-Out jack audio output (and Simultaneous HDMI output with Software Mixing)   
    Hi All,
     
    After I accomplished my IR Red Key Rick Rolling experiment the other day with much success, and from general end-luser use with Armbian, there were two things which irritated me, which are namely due to the default ALSA configuration that comes with stock Debian and that Armbian inherits. These were:
     
    Update: 11 September 2017. This guide will not work for newer Armbiam (Debian) installations which comes with Pulseaudio by default. If you really want what this tutorial provides, you will need to uninstall pulseaudio first: sudo apt-get remove pulseaudio
     
    1) You can't have simultaneous applications using an Audio device. So, how about if I want to stream Internet Radio with 'Radio Tray' but also get system alert sounds, or anything else? Out of luck, you'll get (for example):
    [ao/alsa] Playback open error: Device or resource busy 2) I want to actually have audio going out of the 3.5mm jack (don't really care about video out), better still if it's the same/simultaneous to what is going out via. HDMI. That means if I have a HDMI TV connected then I can get the sound from the TV, if I don't, then I can just use the 3.5mm jack (i.e. If I'm using my Pi to play Rick Astley headless/without a TV). No need to keep editing /etc/asound.conf every time.
     

     
    Solution?
     
    Step 1) Fix the mute on the analog Line-Out in alsamixer (for a start)
     
    There's a lot of noise out there about people not being able to get any sound our of the analog Line-Out jack even when having changed /etc/asound.conf. The reason for this is likely due to a mute by default on the analog audio line-out (i.e. the 3.5mm headphone jack) in alsa that you would unlikely to be aware of. I only found this out thanks to a comment here, otherwise I would have thrown by Pi PC out the window today.
     
    So to fix, you need to type in the console:
    sudo alsamixer Then F6 select the 'audiocodec', then tap the right arrow key to select the 'Audio lineout [Off]' item.
     

     
    Press 'm' and you'll get the green 'OO', which means it's now active.
     

     
    Exit alsamixer, and when you're back at the console type:
    sudo alsactl store 0 ... to store you mixer settings.
     
    For your information, the mixer settings are stored to the file:
    /var/lib/alsa/asound.state  ... and if you do a diff of this file after having made the changes in alsamixer, this is what is changed in the alsa asound.state file:
           control.9 {                                                     control.9 {                 iface MIXER                                                     iface MIXER                 name 'Audio lineout'                                            name 'Audio lineout'                 value false                                   |                 value true                 comment {                                                       comment {                         access 'read write'                                             access 'read write'                         type BOOLEAN                                                    type BOOLEAN                         count 1                                                         count 1                 }                                                               }         }                                                               } Step 2) Change the /etc/asound.conf file
     
    As you might or might not be aware, the default /etc/asound.conf file looks something like this:
     
    pcm.!default {     type hw     card 1 } ctl.!default {     type hw     card 1 } All it is configured to do is give applications direct access to the hardware audio device, and pump the sound either out to the analogue line-out ('card 0') or via HDMI ('card 1'). Pretty basic, but does the job.   However, what I wanted was two things: Software mixing before the resulting PCM/Sound is sent to the hardware audio device - This enables me to listen to Internet Radio and Youtube at the same time... Simultaneous Output to both HDMI and analog line-out. If you want only (1) above, and only via HDMI, then the /etc/asound.conf file is this:
    pcm.!default {   type plug   slave.pcm "dmixer" } pcm.dmixer  {   type dmix   ipc_key 1024   slave {     pcm "hw:1,0" # "hw:1,0" means HDMI change to "hw:0,0" for analog lineout jack output     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.dmixer {   type hw   card 0 } ctl.!default {     type hw     card 0 } If you want (1) and (2) (which of course you do), then the /etc/asound.conf file is this:
    # Thanks to: http://alsa.opensrc.org/Asoundrc#Dupe_output_to_multiple_cards #            https://sourceforge.net/p/alsa/mailman/message/33476395/ # Check that a MUTE doesn't exist on the Audio Line Out for Orange PI PC # or you'll get no sound other than via HDMI pcm.!default {    type plug    slave.pcm "duplicate" } ctl.!default {     type hw     card 0 } # Create the Software Mixer for HDMI and then link to hardware pcm.hdmi-dmixer  {   type dmix   ipc_key 1024   slave {     #pcm "hw:0,0"    # pcm "duplicate"     pcm "hdmi-hw" #    pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.hdmi-dmixer {   type hw   card 0 } # Create the Software Mixer for Analogue Out and then link to hardware pcm.analog-dmixer  {   type dmix   ipc_key 2048   slave {     #pcm "hw:0,0"    # pcm "duplicate"  #   pcm "hdmi-hw"     pcm "analog-hw"     period_time 0     period_size 1024     buffer_size 4096     rate 44100   }   bindings {     0 0     1 1   } } ctl.analog-dmixer {   type hw   card 0 } # Route the audio requests to both hardware devices via the mixer. # For some reason we can't have one mixer and then route to two hardware # devices (would be more efficient). pcm.duplicate {     type route     slave.pcm {         type multi         slaves {             a { pcm "analog-dmixer" channels 2 }             h { pcm "hdmi-dmixer" channels 2 }         }         bindings [             { slave a channel 0 }             { slave a channel 1 }             { slave h channel 0 }             { slave h channel 1 }         ]     }     ttable [         [ 1 0 1 0 ]         [ 0 1 0 1 ]     ] } ctl.duplicate {         type hw;         card 0; } # Physical Output Device Mappings - Analogue and HDMI for Orange PI PC pcm.analog-hw {     type hw     card 0 } pcm.hdmi-hw {     type hw     card 1 }    
    There you have it. The only downside is that CPU usage for playing music will increase a bit as ALSA will essentially route inputs from applications to two Software Mixers, which are connected to the HDMI and Analog Line-Out hardware devices separately. For some reason you can't have a single Software Mixer route to two hardware devices (or I couldn't get it to work), but whatever. We're talking 20% CPU usage vs. 10% on one core, to play music.      
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines