- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#71
A20 / Re: Interrupt EINT31(PI19)
Last post by LubOlimex - April 03, 2024, 09:05:29 AMIt is similar to this:
https://www.olimex.com/forum/index.php?topic=4400.0
EINT are already supported in older sunxi images, and can be used as described in here:
https://github.com/OLIMEX/OLINUXINO/blob/master/SOFTWARE/A20/A20-build-3.4.103-release-7/USAGE-AND-COMMON-PRACTICEs-A20-Olimex_kernel_3.4.103%2B_Jessie_rel_3.txt
Older sunxi images can be found at our FTP.
https://www.olimex.com/forum/index.php?topic=4400.0
EINT are already supported in older sunxi images, and can be used as described in here:
https://github.com/OLIMEX/OLINUXINO/blob/master/SOFTWARE/A20/A20-build-3.4.103-release-7/USAGE-AND-COMMON-PRACTICEs-A20-Olimex_kernel_3.4.103%2B_Jessie_rel_3.txt
Older sunxi images can be found at our FTP.
#72
STMP1 / Re: Olimex STMP1 SOM - Error s...
Last post by LubOlimex - April 03, 2024, 08:42:46 AMYes, we are working on it. As I wrote previously: "Currently, we are prototyping a number of test boards around the AXP209 to exhaust all hardware scenarios." These PCBs were manufactured and tests are currently carried away. This can't be done very quick since there is a lot of hardware tinkering and soldering and empirical testing to reach to the bottom of the issue.
#73
A20 / Re: Interrupt EINT31(PI19)
Last post by Starkafan - April 03, 2024, 08:04:43 AMQuote from: LubOlimex on March 29, 2024, 10:18:50 AMWhat image do you use? For older images you need to edit the fex/bin and define it is for that function (and remove the pin from other usages). It is similar for newer Olimage images but instead of fex/bin you need to change the DTS.
Thank You! I'm use DTS (sun7i-a20-olinuxino-lime2.dts).
1. What to write in dts?
2. How to enable an interrupt in a C program?
#74
A20 / Re: Disable backlight on LCD
Last post by dlombardo - April 03, 2024, 01:10:19 AMIt might be good for closure if somebody is searching for the same.
The LCD control of brightness and backlight power is possible on both legacy Kernel 3.4 and mainline Kernel 5.10 Debian 11 Bullseye images.
For dimming the LCD I have posted a solution in forum reply https://www.olimex.com/forum/index.php?topic=2862.0
Where also the final standby - turning off the LCD is described.
On Kernel 3.4 the monitor power is managed by GPIO and if GPIO is not enabled, then it must be enabled by setting the script.fex -> script.bin file.
On mainline Debian 11 Bullseye image I have managed to controll Display standby / power by either:
For the later option of changing the Device Tree some notes for reference.
Initially Olimex overlay is using LCD enable GPIO in a way that it can not be controlled by setting its value.
Firstly we need to get the Device Tree source and Device Tree Compiler [dtc]
Tested in Ubuntu 18.04 and 20.04.
Setting up the Device Tree source
Build only this Device tree (dont mind the warnings
as default Olimex makefile builds with -q (quiet) anyways)
and upload to the A20
After reboot, the LCD only blinks (as usually) but then does not turn on anymore.
Review of reserved GPIO shows the GPIO is free to use
Manual control of the LCD power is then available using standard GPIO control
The LCD control of brightness and backlight power is possible on both legacy Kernel 3.4 and mainline Kernel 5.10 Debian 11 Bullseye images.
For dimming the LCD I have posted a solution in forum reply https://www.olimex.com/forum/index.php?topic=2862.0
Where also the final standby - turning off the LCD is described.
On Kernel 3.4 the monitor power is managed by GPIO and if GPIO is not enabled, then it must be enabled by setting the script.fex -> script.bin file.
On mainline Debian 11 Bullseye image I have managed to controll Display standby / power by either:
- Disabling power-manager in XFCE and using xset dpms
- Controlling GPIO by updating Device Tree
For the later option of changing the Device Tree some notes for reference.
Initially Olimex overlay is using LCD enable GPIO in a way that it can not be controlled by setting its value.
Firstly we need to get the Device Tree source and Device Tree Compiler [dtc]
Tested in Ubuntu 18.04 and 20.04.
Code Select
git clone --depth 1 --recurse-submodules --shallow-submodules https://github.com/OLIMEX/olinuxino-overlays.git
sudo apt-get install device-tree-compiler
Setting up the Device Tree source
Code Select
cd olinuxino-overlays/sun7i-a20/A20-OLinuXino-Micro
vi micro-lcd-olinuxino-10.dts
where reference to GPIO can be commented out and thus disables default controlCode Select
enable-gpios = <&pio 7 8 0>;
change toCode Select
// Disabling for manual control (DL 20211014) enable-gpios = <&pio 7 8 0>;
Build only this Device tree (dont mind the warnings
as default Olimex makefile builds with -q (quiet) anyways)Code Select
dtc -@ -I dts -O dtb -o micro-lcd-olinuxino-10.dtbo micro-lcd-olinuxino-10.dts
micro-lcd-olinuxino-10.dtbo: Warning (reg_format): "reg" property in /fragment@3/__overlay__/endpoint@0 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
micro-lcd-olinuxino-10.dtbo: Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property
micro-lcd-olinuxino-10.dtbo: Warning (unit_address_vs_reg): Node /fragment@1 has a unit name, but no reg property
micro-lcd-olinuxino-10.dtbo: Warning (unit_address_vs_reg): Node /fragment@2 has a unit name, but no reg property
micro-lcd-olinuxino-10.dtbo: Warning (unit_address_vs_reg): Node /fragment@3 has a unit name, but no reg property
micro-lcd-olinuxino-10.dtbo: Warning (pci_device_reg): Failed prerequisite 'reg_format'
micro-lcd-olinuxino-10.dtbo: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
micro-lcd-olinuxino-10.dtbo: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
micro-lcd-olinuxino-10.dtbo: Warning (avoid_default_addr_size): Relying on default #address-cells value for /fragment@3/__overlay__/endpoint@0
micro-lcd-olinuxino-10.dtbo: Warning (avoid_default_addr_size): Relying on default #size-cells value for /fragment@3/__overlay__/endpoint@0
micro-lcd-olinuxino-10.dtbo: Warning (pwms_property): Property 'pwms', cell 2 is not a phandle reference in /fragment@0/__overlay__/backlight
micro-lcd-olinuxino-10.dtbo: Warning (pwms_property): Could not get phandle node for /fragment@0/__overlay__/backlight:pwms(cell 2)
and upload to the A20
Code Select
scp micro-lcd-olinuxino-10.dtbo root@192.168.2.105:/usr/lib/olinuxino-overlays/sun7i-a20/micro-lcd-olinuxino-10.dtbo
After reboot, the LCD only blinks (as usually) but then does not turn on anymore.
Review of reserved GPIO shows the GPIO is free to use
Code Select
cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-287, parent: platform/1c20800.pinctrl, 1c20800.pinctrl:
gpio-40 ( |ahci-5v ) out hi
gpio-41 ( |usb0-vbus ) out lo
gpio-225 ( |cd ) in lo IRQ ACTIVE LOW
gpio-226 ( |a20-olinuxino-micro:) out hi
gpio-227 ( |usb2-vbus ) out hi
gpio-228 ( |usb0_id_det ) in hi IRQ
gpio-229 ( |usb0_vbus_det ) in lo IRQ
gpio-230 ( |usb1-vbus ) out hi
gpio-235 ( |cd ) in hi IRQ ACTIVE LOW
gpiochip1: GPIOs 413-415, parent: platform/axp20x-gpio, axp20x-gpio, can sleep:
Manual control of the LCD power is then available using standard GPIO control
Code Select
# INIT
echo 232 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio232/direction
# TURN ON
echo 1 > /sys/class/gpio/gpio232/value
# Control Brightness
echo 10 > /sys/class/backlight/backlight/brightness
# TURN OFF
echo 0 > /sys/class/gpio/gpio232/value
#75
A20 / Re: [HOWTO] change LCD brightn...
Last post by dlombardo - April 03, 2024, 12:32:29 AMIt might be interesting I post an update for controlling the LCD Brightness on the newer mainline kernel images - Debian 11 Bullseye.
Tested under XFCE desktop environment.
The brightness can be controlled by setting value in range from 1 to 10 in /sys/class/backlight/backlight/brightness.
For the complete standby of the display I disabled xfce4 power manager and used xset dpms.
Kernel 3.4 Image LCD standby code:
Tested under XFCE desktop environment.
The brightness can be controlled by setting value in range from 1 to 10 in /sys/class/backlight/backlight/brightness.
For the complete standby of the display I disabled xfce4 power manager and used xset dpms.
Code Select
# Disable xfce power-manager monitor control
xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/blank-on-ac -s 0
xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/dpms-on-ac-sleep -s 0
xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/dpms-on-ac-off -s 0
xfconf-query -c xfce4-power-manager -p /xfce4-power-manager/dpms-enabled -s false
# Using xset dpms
xset dpms force on
...
# Turn off display
COUNT=$(cat /sys/class/backlight/backlight/brightness)
while [ $COUNT -gt 1 ]; do
COUNT=$(($COUNT - 1))
echo $COUNT > /sys/class/backlight/backlight/brightness
sleep 0.1
done
# USING xset dpms to turn off the monitor
xset dpms force off
Kernel 3.4 Image LCD standby code:
Code Select
# Turn off display
COUNT=$(cat /sys/class/pwm-sunxi/pwm0/duty_percent)
while [ $COUNT -gt 20 ]; do
COUNT=$(($COUNT - 5))
echo $COUNT > /sys/class/pwm-sunxi/pwm0/duty_percent
sleep 0.1
done
# LCD power GPIO disable
echo 0 > /sys/class/gpio/gpio58_ph8/value # GPIO might be manually added if missing
# echo 0 > /sys/class/gpio/gpio232/value # mainline GPIO
#76
STMP1 / Re: Olimex STMP1 SOM - Error s...
Last post by thom_nic - April 02, 2024, 07:30:00 PMThank you. Is there a plan, or ongoing investigation to solve the root cause and get the AXP209 reliably working again?
#77
SHIELDS / Re: SHIELD-LCD16x2 new firmwar...
Last post by Laurence123 - April 02, 2024, 12:36:30 PMThe main change was to fix the time delays so they are correct (stock firmware has very long time delays, so the Arduino library needs delays of tens of milliseconds when talking to the screen). I have now also modified the Arduino library to have no delays apart from a 2ms delay when clearing the screen.
I also moved the LCD communication out of the interrupt service routine and into the main loop. This avoids the risk of an ISR being un-serviced, which seemed to be the cause of lockups if the delays on the I2C communications were too short (this problem has also been described in previous forum posts). There is now a command buffer between the ISR and the main loop, but at only 100kHz I2C clock speed, it will never get very full. If 400kHz I2C is used then it will start to fill, but currently my firmware does not support >100kHz I2C due to the I2C config register settings on the PIC16F. I haven't tested 400kHz I2C clock as it is not required for my application, but my understanding of the PIC16F datasheet is that when 400kHz mode is configured then there are some hardware timeouts that may cause issues with bit-banged I2C on the Arduino, but I haven't tested this.
The third change was to avoid use of standard string libraries to save flash on the PIC. I also rewrote the UART string handling logic to reduce SRAM use. As a result it's now possible to compile the full code with MPLAB IDE and still have space left over to implement the command buffer between the ISR and main loop.
As a final guard against lockups, I enabled the watchdog timer on the PIC16F and set the timeout to 500ms. It is reset every main loop iteration.
I also moved the LCD communication out of the interrupt service routine and into the main loop. This avoids the risk of an ISR being un-serviced, which seemed to be the cause of lockups if the delays on the I2C communications were too short (this problem has also been described in previous forum posts). There is now a command buffer between the ISR and the main loop, but at only 100kHz I2C clock speed, it will never get very full. If 400kHz I2C is used then it will start to fill, but currently my firmware does not support >100kHz I2C due to the I2C config register settings on the PIC16F. I haven't tested 400kHz I2C clock as it is not required for my application, but my understanding of the PIC16F datasheet is that when 400kHz mode is configured then there are some hardware timeouts that may cause issues with bit-banged I2C on the Arduino, but I haven't tested this.
The third change was to avoid use of standard string libraries to save flash on the PIC. I also rewrote the UART string handling logic to reduce SRAM use. As a result it's now possible to compile the full code with MPLAB IDE and still have space left over to implement the command buffer between the ISR and main loop.
As a final guard against lockups, I enabled the watchdog timer on the PIC16F and set the timeout to 500ms. It is reset every main loop iteration.
#78
SHIELDS / Re: SHIELD-LCD16x2 new firmwar...
Last post by LubOlimex - April 01, 2024, 12:00:56 PMIt compiles now and seems to work fine but we are a bit lost what does the changes do. Many changes and will take us a lot of time to understand everything. Care to explain what are the main improvements in your firmware?
Maybe we will provide it as alternative option on the web-site if someone else wants to test it.
Maybe we will provide it as alternative option on the web-site if someone else wants to test it.
#79
STMP1 / Re: Olimex STMP1 SOM - Error s...
Last post by LubOlimex - April 01, 2024, 10:51:56 AMI can give you the diff files with the changes, find them here:
https://ftp.olimex.com/TEMP/SOM-NO-AXP209/DIFF-files/
Not sure if we will make a fork or branch in the public repo without AXP209 since it is a workaround that might suit people with startup issues but would hinder people that need AXP209 tools.
Removing the AXP209 for the boards with HDMI connector is especially risky (like the STMP157-OLinuXino-LIME2 and STMP157-BASE-SOM-EVB).
https://ftp.olimex.com/TEMP/SOM-NO-AXP209/DIFF-files/
Not sure if we will make a fork or branch in the public repo without AXP209 since it is a workaround that might suit people with startup issues but would hinder people that need AXP209 tools.
Removing the AXP209 for the boards with HDMI connector is especially risky (like the STMP157-OLinuXino-LIME2 and STMP157-BASE-SOM-EVB).
#80
TERES DIY Laptop / Re: Teres-1 debug console
Last post by DiTBho - March 30, 2024, 06:24:22 PMI don't have a Teres-1 laptop on hand at the moment, without configuring anything on the port-L of the GPIO, what is the default behavior?
At early boot, without configuring the GPIO port L by neither uboot nor kernel, is the uart0 connected to jack or is audio connected to jack?
At early boot, without configuring the GPIO port L by neither uboot nor kernel, is the uart0 connected to jack or is audio connected to jack?