adrb

It's simple guide, presenting how to setup LCD (ili9431) with integrated touchscreen (tsc2046) on mainline kernel (4.11). It may be not fully "armbian way", since I'm pretty new in armbian
 
In case that somebody is interested, I recently bought couple those displays from here
 
Few basic informations:
 
1. OrangePiZero has two SPI buses. First one is usually occupied by build in memory. So we can only use bus1
2. tsc2046 chip is fully compatible with ads7846, and we have drivers for it since years now
3. Maximum clock frequency for ads7846 is 3.25Mhz, but don't expect that it will work with that.  Reasonable value is something beetween 0.5-2Mhz. Lower frequency, if you observing misbehavior.
4. Probably most important information  ili9431 and tsc2046 poorly cooperate on shared bus. I don't know exactly why, because I don't have access to logic analyzer,  but it's proven fact (at least on my equipment). You have to lower bus frequency to 2MHz (highest common value), and even then it work very unstable.  My educated guess is that, missed interrupt from touchscreen (when SPI is busy with sending data to LCD) makes it stop making further attempts to communicate. Or maybe there is some incompatibility on electrical level, I really don't know.
5. My electrical setup (keep in mind it's 3.3V)
 
OPIZ - LCD (ili9431)
PA13 - CS
PA14 - SCK
PA16 - SDO
PA15 - SDI
PA03 - DC
PA00 - RESET
PA06 - controls transistor which is driving current to LCD pin. You may also connect LCD pin to VCC, and leave PA06 floating.
 
And here is part for touchscreen. We are going to use emulated spi bus with bitbang. At this point bitbang isn't compiled in armbian kernel - we will take care of this later.
 
OPIZ - LCD (tsc2046)
PA10 - T_CS
PA18 - T_IRQ
PA19 - T_CLK
PA11 - T_DIN
PA12 - T_DO
 
Configuration for the first spi bus:
 
Configuration for touchscreen driver:
 
Compile and add those DTS with "armbian-add-overlay" command.
Next, download armbian sources and cross compile kernel - without any modifications, just to make sure that everything is compiling without issues:
# mkdir armbian # cd armbian # git clone https://github.com/armbian/build.git # git clone https://github.com/igorpecovnik/lib # cp lib/compile.sh . # ./compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=jessie Enable required modules :
echo "CONFIG_SPI_BITBANG=m" >> lib/config/kernel/linux-sun8i-dev.config echo "CONFIG_SPI_GPIO=m" >> lib/config/kernel/linux-sun8i-dev.config ... and recompile kernel, then install deb packages from output directory. You may also copy drivers, it may be faster for testing but it's not advised for "serious" deployment.
Loading modules at startup:
# cat > /etc/modprobe.d/fb_ili9341.conf << _EOF_ options fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1 _EOF_ # echo fbtft_device >> /etc/modules # echo ads7846 >> /etc/modules If you connected LED pin to VCC, then you should omit that ",led:6" in configuration above. 
 
I hope that this will help anyone who want to connect LCD display and build simple touchscreen based Orange Pi Zero terminal

 
 

It's simple guide, presenting how to setup LCD (ili9431) with integrated touchscreen (tsc2046) on mainline kernel (4.11). It may be not fully "armbian way", since I'm pretty new in armbian
 
In case that somebody is interested, I recently bought couple those displays from here
 
Few basic informations:
 
1. OrangePiZero has two SPI buses. First one is usually occupied by build in memory. So we can only use bus1
2. tsc2046 chip is fully compatible with ads7846, and we have drivers for it since years now
3. Maximum clock frequency for ads7846 is 3.25Mhz, but don't expect that it will work with that.  Reasonable value is something beetween 0.5-2Mhz. Lower frequency, if you observing misbehavior.
4. Probably most important information  ili9431 and tsc2046 poorly cooperate on shared bus. I don't know exactly why, because I don't have access to logic analyzer,  but it's proven fact (at least on my equipment). You have to lower bus frequency to 2MHz (highest common value), and even then it work very unstable.  My educated guess is that, missed interrupt from touchscreen (when SPI is busy with sending data to LCD) makes it stop making further attempts to communicate. Or maybe there is some incompatibility on electrical level, I really don't know.
5. My electrical setup (keep in mind it's 3.3V)
 
OPIZ - LCD (ili9431)
PA13 - CS
PA14 - SCK
PA16 - SDO
PA15 - SDI
PA03 - DC
PA00 - RESET
PA06 - controls transistor which is driving current to LCD pin. You may also connect LCD pin to VCC, and leave PA06 floating.
 
And here is part for touchscreen. We are going to use emulated spi bus with bitbang. At this point bitbang isn't compiled in armbian kernel - we will take care of this later.
 
OPIZ - LCD (tsc2046)
PA10 - T_CS
PA18 - T_IRQ
PA19 - T_CLK
PA11 - T_DIN
PA12 - T_DO
 
Configuration for the first spi bus:
 
Configuration for touchscreen driver:
 
Compile and add those DTS with "armbian-add-overlay" command.
Next, download armbian sources and cross compile kernel - without any modifications, just to make sure that everything is compiling without issues:
# mkdir armbian # cd armbian # git clone https://github.com/armbian/build.git # git clone https://github.com/igorpecovnik/lib # cp lib/compile.sh . # ./compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=jessie Enable required modules :
echo "CONFIG_SPI_BITBANG=m" >> lib/config/kernel/linux-sun8i-dev.config echo "CONFIG_SPI_GPIO=m" >> lib/config/kernel/linux-sun8i-dev.config ... and recompile kernel, then install deb packages from output directory. You may also copy drivers, it may be faster for testing but it's not advised for "serious" deployment.
Loading modules at startup:
# cat > /etc/modprobe.d/fb_ili9341.conf << _EOF_ options fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1 _EOF_ # echo fbtft_device >> /etc/modules # echo ads7846 >> /etc/modules If you connected LED pin to VCC, then you should omit that ",led:6" in configuration above. 
 
I hope that this will help anyone who want to connect LCD display and build simple touchscreen based Orange Pi Zero terminal

 
 

It's simple guide, presenting how to setup LCD (ili9431) with integrated touchscreen (tsc2046) on mainline kernel (4.11). It may be not fully "armbian way", since I'm pretty new in armbian
 
In case that somebody is interested, I recently bought couple those displays from here
 
Few basic informations:
 
1. OrangePiZero has two SPI buses. First one is usually occupied by build in memory. So we can only use bus1
2. tsc2046 chip is fully compatible with ads7846, and we have drivers for it since years now
3. Maximum clock frequency for ads7846 is 3.25Mhz, but don't expect that it will work with that.  Reasonable value is something beetween 0.5-2Mhz. Lower frequency, if you observing misbehavior.
4. Probably most important information  ili9431 and tsc2046 poorly cooperate on shared bus. I don't know exactly why, because I don't have access to logic analyzer,  but it's proven fact (at least on my equipment). You have to lower bus frequency to 2MHz (highest common value), and even then it work very unstable.  My educated guess is that, missed interrupt from touchscreen (when SPI is busy with sending data to LCD) makes it stop making further attempts to communicate. Or maybe there is some incompatibility on electrical level, I really don't know.
5. My electrical setup (keep in mind it's 3.3V)
 
OPIZ - LCD (ili9431)
PA13 - CS
PA14 - SCK
PA16 - SDO
PA15 - SDI
PA03 - DC
PA00 - RESET
PA06 - controls transistor which is driving current to LCD pin. You may also connect LCD pin to VCC, and leave PA06 floating.
 
And here is part for touchscreen. We are going to use emulated spi bus with bitbang. At this point bitbang isn't compiled in armbian kernel - we will take care of this later.
 
OPIZ - LCD (tsc2046)
PA10 - T_CS
PA18 - T_IRQ
PA19 - T_CLK
PA11 - T_DIN
PA12 - T_DO
 
Configuration for the first spi bus:
 
Configuration for touchscreen driver:
 
Compile and add those DTS with "armbian-add-overlay" command.
Next, download armbian sources and cross compile kernel - without any modifications, just to make sure that everything is compiling without issues:
# mkdir armbian # cd armbian # git clone https://github.com/armbian/build.git # git clone https://github.com/igorpecovnik/lib # cp lib/compile.sh . # ./compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=jessie Enable required modules :
echo "CONFIG_SPI_BITBANG=m" >> lib/config/kernel/linux-sun8i-dev.config echo "CONFIG_SPI_GPIO=m" >> lib/config/kernel/linux-sun8i-dev.config ... and recompile kernel, then install deb packages from output directory. You may also copy drivers, it may be faster for testing but it's not advised for "serious" deployment.
Loading modules at startup:
# cat > /etc/modprobe.d/fb_ili9341.conf << _EOF_ options fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1 _EOF_ # echo fbtft_device >> /etc/modules # echo ads7846 >> /etc/modules If you connected LED pin to VCC, then you should omit that ",led:6" in configuration above. 
 
I hope that this will help anyone who want to connect LCD display and build simple touchscreen based Orange Pi Zero terminal

 
 

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

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

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

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

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

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

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

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

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

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

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

Illustration 3: Recommended powersource
 
 

For those of you who are interested in using a OPI zero as a small IoT-Server. I have some hints to get it working. It's more or less a lmgtfy How To plus some arduino code to test if it works.
Hardware:
OrangePi 0 with Armbian 5.25 connected over lan to my router DHT11 Module on a Wemos D1 mini (a small cheap wlan MCU for ~3$ which can be programmed via the Arduino IDE) Installation:
First of all we install node-red on the OPI. Instead of rewrite how to do that again I just give you the link who to do that: Node-Red on armbian
Second we install Mosquitto as a mqtt broker. If I have it right in mind I followed this instructable (I'm not shure, it's more than 2 weeks ago and I didn't save the link then): Mosquitto
To represent the data of our DHT sensor-node graphically we install the node red dashboard module in: /usr/lib/node_modules/
with npm i node-red-dashboard
If everything goes right you should have access to node-red via browser on port 1880:
192.168.1.xx:1880
and to the UI of dashboard:
192.168.1.xx:1880/ui/
Setting up everything:
Now we're setting up the Wemos D1 mini. DHT11 wiring (DHT-->Wemos):
VCC -->3.3V 
Signal --> D4
GND -->GND
Some of the Wemos pins are capable for 5V (A0 definitly not!) but the DHT readings gets noisier when the device is powered through 5V (don't ask me why, I'm not en electronic engineer...)
For the testprogramm we need two libraries which can be installed via the arduino IDE lib manager (+ ESP8266WiFi.h which comes when adding the generic ESP8266 board via Boardmanager):
PubSubClient.h (PubSubClient by Nick O'Leary) DHT.h (DHT sensor library by Adafruit) And here comes the simplyfied code publishing to the mqtt broker:
The code is more or less a combination of the examples which comes with the PubSubClient & DHT libraries + throw away all the stuff that we don't need (I had also a version of code where the Wemos D1 mini subscribe to the mqtt broker and gets a timestamp injected from node-red which was then added to the published sensor data).
Humidity data is stored in the "hum" topic, temperature in "temp". Keep in mind that if you plan use more than one senor-node, you should name the topics properly (see: MQTT topics best practices for more information about proper topic nameing)
We can now generate our test-flow on the node-red webpage (See printscreen). Subscribe to the mqtt topics and publish it on the chart and gauge (more information about Dashboard can be found on: Node-Red & Dashboard). 
Powering the Wemos and deploy the created flow shoud show us the graphs on 192.168.1.xx:1880/ui/ (see picture)
To call me an IoT expert is like someone calling tkaiser a fan of micro USB powered SBCs. According to the MIT licence this HowTo  is provided "as is", without warranty etc.

It's simple guide, presenting how to setup LCD (ili9431) with integrated touchscreen (tsc2046) on mainline kernel (4.11). It may be not fully "armbian way", since I'm pretty new in armbian
 
In case that somebody is interested, I recently bought couple those displays from here
 
Few basic informations:
 
1. OrangePiZero has two SPI buses. First one is usually occupied by build in memory. So we can only use bus1
2. tsc2046 chip is fully compatible with ads7846, and we have drivers for it since years now
3. Maximum clock frequency for ads7846 is 3.25Mhz, but don't expect that it will work with that.  Reasonable value is something beetween 0.5-2Mhz. Lower frequency, if you observing misbehavior.
4. Probably most important information  ili9431 and tsc2046 poorly cooperate on shared bus. I don't know exactly why, because I don't have access to logic analyzer,  but it's proven fact (at least on my equipment). You have to lower bus frequency to 2MHz (highest common value), and even then it work very unstable.  My educated guess is that, missed interrupt from touchscreen (when SPI is busy with sending data to LCD) makes it stop making further attempts to communicate. Or maybe there is some incompatibility on electrical level, I really don't know.
5. My electrical setup (keep in mind it's 3.3V)
 
OPIZ - LCD (ili9431)
PA13 - CS
PA14 - SCK
PA16 - SDO
PA15 - SDI
PA03 - DC
PA00 - RESET
PA06 - controls transistor which is driving current to LCD pin. You may also connect LCD pin to VCC, and leave PA06 floating.
 
And here is part for touchscreen. We are going to use emulated spi bus with bitbang. At this point bitbang isn't compiled in armbian kernel - we will take care of this later.
 
OPIZ - LCD (tsc2046)
PA10 - T_CS
PA18 - T_IRQ
PA19 - T_CLK
PA11 - T_DIN
PA12 - T_DO
 
Configuration for the first spi bus:
 
Configuration for touchscreen driver:
 
Compile and add those DTS with "armbian-add-overlay" command.
Next, download armbian sources and cross compile kernel - without any modifications, just to make sure that everything is compiling without issues:
# mkdir armbian # cd armbian # git clone https://github.com/armbian/build.git # git clone https://github.com/igorpecovnik/lib # cp lib/compile.sh . # ./compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=jessie Enable required modules :
echo "CONFIG_SPI_BITBANG=m" >> lib/config/kernel/linux-sun8i-dev.config echo "CONFIG_SPI_GPIO=m" >> lib/config/kernel/linux-sun8i-dev.config ... and recompile kernel, then install deb packages from output directory. You may also copy drivers, it may be faster for testing but it's not advised for "serious" deployment.
Loading modules at startup:
# cat > /etc/modprobe.d/fb_ili9341.conf << _EOF_ options fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1 _EOF_ # echo fbtft_device >> /etc/modules # echo ads7846 >> /etc/modules If you connected LED pin to VCC, then you should omit that ",led:6" in configuration above. 
 
I hope that this will help anyone who want to connect LCD display and build simple touchscreen based Orange Pi Zero terminal

 
 

It's simple guide, presenting how to setup LCD (ili9431) with integrated touchscreen (tsc2046) on mainline kernel (4.11). It may be not fully "armbian way", since I'm pretty new in armbian
 
In case that somebody is interested, I recently bought couple those displays from here
 
Few basic informations:
 
1. OrangePiZero has two SPI buses. First one is usually occupied by build in memory. So we can only use bus1
2. tsc2046 chip is fully compatible with ads7846, and we have drivers for it since years now
3. Maximum clock frequency for ads7846 is 3.25Mhz, but don't expect that it will work with that.  Reasonable value is something beetween 0.5-2Mhz. Lower frequency, if you observing misbehavior.
4. Probably most important information  ili9431 and tsc2046 poorly cooperate on shared bus. I don't know exactly why, because I don't have access to logic analyzer,  but it's proven fact (at least on my equipment). You have to lower bus frequency to 2MHz (highest common value), and even then it work very unstable.  My educated guess is that, missed interrupt from touchscreen (when SPI is busy with sending data to LCD) makes it stop making further attempts to communicate. Or maybe there is some incompatibility on electrical level, I really don't know.
5. My electrical setup (keep in mind it's 3.3V)
 
OPIZ - LCD (ili9431)
PA13 - CS
PA14 - SCK
PA16 - SDO
PA15 - SDI
PA03 - DC
PA00 - RESET
PA06 - controls transistor which is driving current to LCD pin. You may also connect LCD pin to VCC, and leave PA06 floating.
 
And here is part for touchscreen. We are going to use emulated spi bus with bitbang. At this point bitbang isn't compiled in armbian kernel - we will take care of this later.
 
OPIZ - LCD (tsc2046)
PA10 - T_CS
PA18 - T_IRQ
PA19 - T_CLK
PA11 - T_DIN
PA12 - T_DO
 
Configuration for the first spi bus:
 
Configuration for touchscreen driver:
 
Compile and add those DTS with "armbian-add-overlay" command.
Next, download armbian sources and cross compile kernel - without any modifications, just to make sure that everything is compiling without issues:
# mkdir armbian # cd armbian # git clone https://github.com/armbian/build.git # git clone https://github.com/igorpecovnik/lib # cp lib/compile.sh . # ./compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=jessie Enable required modules :
echo "CONFIG_SPI_BITBANG=m" >> lib/config/kernel/linux-sun8i-dev.config echo "CONFIG_SPI_GPIO=m" >> lib/config/kernel/linux-sun8i-dev.config ... and recompile kernel, then install deb packages from output directory. You may also copy drivers, it may be faster for testing but it's not advised for "serious" deployment.
Loading modules at startup:
# cat > /etc/modprobe.d/fb_ili9341.conf << _EOF_ options fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1 _EOF_ # echo fbtft_device >> /etc/modules # echo ads7846 >> /etc/modules If you connected LED pin to VCC, then you should omit that ",led:6" in configuration above. 
 
I hope that this will help anyone who want to connect LCD display and build simple touchscreen based Orange Pi Zero terminal

 
 

Requirements
Fresh enough nighly or manually built image Latest kernel and dtb packages (26.03.2017 or newer)  
Limitations
As stated in other PWM related threads, hardware PWM output is supported only on pin PA5 which is also UART0 ("debug" serial console) RX pin, so enabling PWM will disable this console.
 
Activation
Add "pwm" to "overlays" line in /boot/armbianEnv.txt
Example:
overlays=pwm Reboot is required to apply the changes
Armbian overlays documentation: https://docs.armbian.com/User-Guide_Allwinner_overlays/
 
PWM sysfs interface
Official documentation: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/ABI/testing/sysfs-class-pwm?h=v4.10
Please note that this ABI is considered "testing" so it may change in the future.
 
Sysfs interface example
# activate the PWM. On H3 only 1 PWM is supported, so exporting PWM 0 echo 0 > /sys/class/pwm/pwmchip0/export # set period to 10ms echo 10000000 > /sys/class/pwm/pwmchip0/pwm0/period # set normal polarity. needs to be reset explicitly. Bug? echo "inversed" > /sys/class/pwm/pwmchip0/pwm0/polarity echo "normal" > /sys/class/pwm/pwmchip0/pwm0/polarity # enable the PWM echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable # set duty cycle to 1ms echo 1000000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle Result:
# set duty cycle to 2ms echo 2000000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle Result:
 
# set duty cycle to 1us, period to 2us echo 1000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle echo 2000 > /sys/class/pwm/pwmchip0/pwm0/period Result:
 
Please note that some settings needs to be changed in a correct sequence, i.e. you can't set duty cycle higher than period
root@orangepiplus2e:~# echo 1000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle root@orangepiplus2e:~# echo 500 > /sys/class/pwm/pwmchip0/pwm0/period -bash: echo: write error: Invalid argument root@orangepiplus2e:~#  

It's simple guide, presenting how to setup LCD (ili9431) with integrated touchscreen (tsc2046) on mainline kernel (4.11). It may be not fully "armbian way", since I'm pretty new in armbian
 
In case that somebody is interested, I recently bought couple those displays from here
 
Few basic informations:
 
1. OrangePiZero has two SPI buses. First one is usually occupied by build in memory. So we can only use bus1
2. tsc2046 chip is fully compatible with ads7846, and we have drivers for it since years now
3. Maximum clock frequency for ads7846 is 3.25Mhz, but don't expect that it will work with that.  Reasonable value is something beetween 0.5-2Mhz. Lower frequency, if you observing misbehavior.
4. Probably most important information  ili9431 and tsc2046 poorly cooperate on shared bus. I don't know exactly why, because I don't have access to logic analyzer,  but it's proven fact (at least on my equipment). You have to lower bus frequency to 2MHz (highest common value), and even then it work very unstable.  My educated guess is that, missed interrupt from touchscreen (when SPI is busy with sending data to LCD) makes it stop making further attempts to communicate. Or maybe there is some incompatibility on electrical level, I really don't know.
5. My electrical setup (keep in mind it's 3.3V)
 
OPIZ - LCD (ili9431)
PA13 - CS
PA14 - SCK
PA16 - SDO
PA15 - SDI
PA03 - DC
PA00 - RESET
PA06 - controls transistor which is driving current to LCD pin. You may also connect LCD pin to VCC, and leave PA06 floating.
 
And here is part for touchscreen. We are going to use emulated spi bus with bitbang. At this point bitbang isn't compiled in armbian kernel - we will take care of this later.
 
OPIZ - LCD (tsc2046)
PA10 - T_CS
PA18 - T_IRQ
PA19 - T_CLK
PA11 - T_DIN
PA12 - T_DO
 
Configuration for the first spi bus:
 
Configuration for touchscreen driver:
 
Compile and add those DTS with "armbian-add-overlay" command.
Next, download armbian sources and cross compile kernel - without any modifications, just to make sure that everything is compiling without issues:
# mkdir armbian # cd armbian # git clone https://github.com/armbian/build.git # git clone https://github.com/igorpecovnik/lib # cp lib/compile.sh . # ./compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=jessie Enable required modules :
echo "CONFIG_SPI_BITBANG=m" >> lib/config/kernel/linux-sun8i-dev.config echo "CONFIG_SPI_GPIO=m" >> lib/config/kernel/linux-sun8i-dev.config ... and recompile kernel, then install deb packages from output directory. You may also copy drivers, it may be faster for testing but it's not advised for "serious" deployment.
Loading modules at startup:
# cat > /etc/modprobe.d/fb_ili9341.conf << _EOF_ options fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1 _EOF_ # echo fbtft_device >> /etc/modules # echo ads7846 >> /etc/modules If you connected LED pin to VCC, then you should omit that ",led:6" in configuration above. 
 
I hope that this will help anyone who want to connect LCD display and build simple touchscreen based Orange Pi Zero terminal

 
 

It's simple guide, presenting how to setup LCD (ili9431) with integrated touchscreen (tsc2046) on mainline kernel (4.11). It may be not fully "armbian way", since I'm pretty new in armbian
 
In case that somebody is interested, I recently bought couple those displays from here
 
Few basic informations:
 
1. OrangePiZero has two SPI buses. First one is usually occupied by build in memory. So we can only use bus1
2. tsc2046 chip is fully compatible with ads7846, and we have drivers for it since years now
3. Maximum clock frequency for ads7846 is 3.25Mhz, but don't expect that it will work with that.  Reasonable value is something beetween 0.5-2Mhz. Lower frequency, if you observing misbehavior.
4. Probably most important information  ili9431 and tsc2046 poorly cooperate on shared bus. I don't know exactly why, because I don't have access to logic analyzer,  but it's proven fact (at least on my equipment). You have to lower bus frequency to 2MHz (highest common value), and even then it work very unstable.  My educated guess is that, missed interrupt from touchscreen (when SPI is busy with sending data to LCD) makes it stop making further attempts to communicate. Or maybe there is some incompatibility on electrical level, I really don't know.
5. My electrical setup (keep in mind it's 3.3V)
 
OPIZ - LCD (ili9431)
PA13 - CS
PA14 - SCK
PA16 - SDO
PA15 - SDI
PA03 - DC
PA00 - RESET
PA06 - controls transistor which is driving current to LCD pin. You may also connect LCD pin to VCC, and leave PA06 floating.
 
And here is part for touchscreen. We are going to use emulated spi bus with bitbang. At this point bitbang isn't compiled in armbian kernel - we will take care of this later.
 
OPIZ - LCD (tsc2046)
PA10 - T_CS
PA18 - T_IRQ
PA19 - T_CLK
PA11 - T_DIN
PA12 - T_DO
 
Configuration for the first spi bus:
 
Configuration for touchscreen driver:
 
Compile and add those DTS with "armbian-add-overlay" command.
Next, download armbian sources and cross compile kernel - without any modifications, just to make sure that everything is compiling without issues:
# mkdir armbian # cd armbian # git clone https://github.com/armbian/build.git # git clone https://github.com/igorpecovnik/lib # cp lib/compile.sh . # ./compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=jessie Enable required modules :
echo "CONFIG_SPI_BITBANG=m" >> lib/config/kernel/linux-sun8i-dev.config echo "CONFIG_SPI_GPIO=m" >> lib/config/kernel/linux-sun8i-dev.config ... and recompile kernel, then install deb packages from output directory. You may also copy drivers, it may be faster for testing but it's not advised for "serious" deployment.
Loading modules at startup:
# cat > /etc/modprobe.d/fb_ili9341.conf << _EOF_ options fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1 _EOF_ # echo fbtft_device >> /etc/modules # echo ads7846 >> /etc/modules If you connected LED pin to VCC, then you should omit that ",led:6" in configuration above. 
 
I hope that this will help anyone who want to connect LCD display and build simple touchscreen based Orange Pi Zero terminal