LVGL_Micropython - driver for ST7701 #76
Replies: 24 comments 40 replies
-
|
The SPI that is used for the configuration is a bit different. It is at an extremely low speed and it needs to he handled by a special driver and not your typical SPI that is available for an MCU. I have not added the special driver yet that is needed to handle the config. You do have the ability to write your own bit bang driver in python to handle turning the pins on and off when they need to be turned on and off using the viper code emitter for MicroPython. RGB bus is going to be limited to 16 lanes for the ESP32. This is a limitation that is set by the ESP SDK. That means the maximum you can set the color depth to is going to be 16 bit which is RGB565.... Instead of using extra pins for the config SPI you can share the pins with some of the lanes for the RGB. You would have to run the config settings and then set up the bus driver and display driver. You will not be able to send any config settings while the display is active if you do this. |
Beta Was this translation helpful? Give feedback.
-
|
HEY!!!! I wanted to let you know that I wrote in the handling of that funky SPI config IC. I am going to key up a display driver for it right now for your display.... It shouldn't take me that long to put together for ya. Maybe 20 minutes or so. |
Beta Was this translation helpful? Give feedback.
-
|
WOWWWW.... I saw that updated in GitHub,.... nice... I'm testing right now |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
ok Kevin, I changed to '480 x 480 x 2' allocated in MEMORY_SPIRAM, its OK. But when start de app the backlight turn on, but I lost the connection in ThonnyIDE and nothing on the screen. is it correct my display_bus using lcd_bus.RGBBus(...) ?? |
Beta Was this translation helpful? Give feedback.
-
|
don't use thonny. It is known to cause problems because of how it resets the ESP32. Always use the reset button on the ESP32 and use a terminal program like putty to connect using serial. You can use thonny to transfer files but make sure to press the reset button after you disconnect thonny |
Beta Was this translation helpful? Give feedback.
-
|
You are correct to use the RGB Bus. I don't know if your pin assignments are correct or not. I would need a link to the data sheets for the board you are using to determine that. |
Beta Was this translation helpful? Give feedback.
-
|
I thinks the pins are ok, because I test it with Arduino GFX and works fine. I'm using putty to monitor serial and I'm trying with Thonny WebRepl but the screen is black, just the backlight power on, but de button test does not show in the LCD. `from micropython import const # NOQA _WIDTH = const(480) _BUFFER_SIZE = int(_WIDTH * _HEIGHT * 2) import lcd_bus # NOQA spi3wire = lcd_bus.SPI3Wire( display_bus = lcd_bus.RGBBus( import st7701 lcd_bus.MEMORY_SPIRAMfb1 = display_bus.allocate_framebuffer(_BUFFER_SIZE, lcd_bus.MEMORY_SPIRAM)#lcd_bus.MEMORY_INTERNAL | lcd_bus.MEMORY_DMA) display = st7701.ST7701( print('olaaa') display.set_power(True) import i2c i2c_bus = i2c.I2CBus(scl=45, sda=19, use_locks=False)indev = gt911.GT911(i2c_bus)lv.init() scrn = lv.screen_active() slider = lv.slider(scrn) label = lv.label(scrn) import task_handler ` |
Beta Was this translation helpful? Give feedback.
-
|
I have the same problem,and I am sure that it's beacuse the SPI doesn't init correctly. |
Beta Was this translation helpful? Give feedback.
-
|
Hello. Driver for ST7701 now work or not ? I can do some test. |
Beta Was this translation helpful? Give feedback.
-
|
need some testing on the 3wire SPI interface portion of the driver. That is what is not working properly. |
Beta Was this translation helpful? Give feedback.
-
|
I received https://homeding.github.io/boards/esp32s3/panel-4848S040.htm that panel. Build firmware and flash on device. Now work only backlight. may be some new info https://components.espressif.com/components/espressif/esp_lcd_st7701 |
Beta Was this translation helpful? Give feedback.
-
https://github.com/jd3096-mpy/micropython-3-wire-spi-soft |
Beta Was this translation helpful? Give feedback.
-
|
would it be OMK if I encoporate that into the binding? I would make sure to long to where the code came from and also give a TY to you fro writing it. This would be done in comments in the source file. |
Beta Was this translation helpful? Give feedback.
-
|
Also infor from ESPHOME https://devices.esphome.io/devices/Guition-ESP32-S3-4848S040 |
Beta Was this translation helpful? Give feedback.
-
|
try using the version that @jd3096-mpy posted and use it with the rgb_display driver. Run the 3wire prior to building the display driver and see if it works. The one that I added last night was a test to see if it would work. The reason why I went that route is I need to be able to disable the 3wire spi if the pins are shared with the display bus. |
Beta Was this translation helpful? Give feedback.
-
|
There are a couple of things that I know I need to change in my version which is the reason why I didn't tell anyone that I had added it. One of the things is I need to change how it is handling rotation which the st7701 doesn't support. |
Beta Was this translation helpful? Give feedback.
-
|
Need some change also. Now I am tested with https://devices.esphome.io/devices/Guition-ESP32-S3-4848S040 - that works. |
Beta Was this translation helpful? Give feedback.
-
|
I did that for 480x480 square (86 Box) GUITION ESP32-4848S040
|
Beta Was this translation helpful? Give feedback.
-
|
Code: lcd_9bit_spi.py lcd.py st7701.py |
Beta Was this translation helpful? Give feedback.
-
|
The problem is you guys are making it specific to just the st7701 display IC. There are many other display IC's that use a 3 wire low speed SPI and there needs to be settings that allow it to work across the board. Putting the init commands into the 3wire isn't the right thing to do. they need to be put in with the actual display and the commands should be passed from the display driver to the 3 wire driver. |
Beta Was this translation helpful? Give feedback.
-
|
Absolutely right. But before that not work and not was understand problem in driver 3-wire or in setting. Now we have right setting. And can back to day ago and try use 3-wire SPI with right setting. |
Beta Was this translation helpful? Give feedback.
-
|
just update _st7701_type9.py now work and color right (set RED background) and without artifact. |
Beta Was this translation helpful? Give feedback.
-
|
for i2c touch for 19 pin, default use as USB-. Need reconfigure firmware. sdkconfig.board mpconfigboard.h |
Beta Was this translation helpful? Give feedback.
-
|
usb should be disabled by default. only when you supply --osb-otg as a build parameter does it turn on. I recommend not changing anything in the config files because the script looks for specific markers in the files to update them. If you change something and it is used as a marker it could cause problems.\ If the pin is still enabled as USB let me know and I will look into why it is not being free'd.. |
Beta Was this translation helpful? Give feedback.
-
|
Also any of the |
Beta Was this translation helpful? Give feedback.
-
|
The ST7701 display IC is a royal pain in the ass. It is very sensitive to the config settings that gets passed to it. They have to be just right otherwise it will not work. I added the config settings the way that I did so it doesn't gobble up a huge amount of memory so only one set of config settings gets loaded. I have to add in deleting the module from memory once it has finished running. haven't gotten to that yet. no need to chew up memory only to run once then done code. I am thinking about changing all of the init commands for all of the display drivers to be that way. |
Beta Was this translation helpful? Give feedback.
-
|
If use own board config and with own micropython i just want use make with your code as user_module. It ok for me. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
working config: on today. Work with file from repo as is. 480x480 square (86 Box) GUITION ESP32-4848S040 display PWM frequency for backlight - 2000display._backlight_pin.freq(2000) |
Beta Was this translation helpful? Give feedback.
-
|
How it works. 2024-09-21.08.44.42.mp4 |
Beta Was this translation helpful? Give feedback.
-
|
OK so what did you have to do to get it to work? or is everything working properly now out of the box? I did make it easier to extend the initialization commands. you need to create a python file named You pass that number as the |
Beta Was this translation helpful? Give feedback.
-
|
Looks like ya have to override the indev callback function in the touch driver to handle the display dimming a little bit better... |
Beta Was this translation helpful? Give feedback.
-
Now work stock "display.init(9)" 9 type from the Box. I am don't change any. |
Beta Was this translation helpful? Give feedback.
-
|
@kdschlosser what is the new setting for the latest driver? Any questions: why need copy_puxel anyway if use rotation0? Now I just back old method. That works for me. |
Beta Was this translation helpful? Give feedback.
-
|
the reason why there is that copy task is to get better performance. It allows LVGL to render to a much smaller partial buffer instead of having to render the full sized frame buffer over and over again. The full sized frame buffers do still exist but they are hidden behind the scenes. The partial buffer gets copied to the large frame buffer on core 0 where as LVGL and MicroPython run on core 1. This speeds up the RGB driver by quite a bit because it allows LVGL and the users application to keep on doing it's thing. While the data is being sent to the display using DMA memory the full frame buffers are so large in size that it takes multiple interrupts to create a new transaction for the transmit. These interrupts no longer take place on the same core that LVGL and MicroPython are running on. Instead they take place on core 0. this once again helps to speed things up. Core 0 on the ESP32 goes largely unused when using MicroPython. It is used to back end Bluetooth relates stuff and some other IO related tasks which don't use a lot of processor time. So why not put that additional processing core to some good use? |
Beta Was this translation helpful? Give feedback.
-
|
@kdschlosser When the slider moves - lcd draws with artifacts. |
Beta Was this translation helpful? Give feedback.
-
|
OK cool. There are lots of changes I have recently made to the RGB driver to improve the performance of it. I more than likely need to adjust something. Do me a favor tho. can you adjust the buffer size to be 1/10th the size instead of being 1/20th the size. Also use 2 buffers instead of 1. This will give you better performance. The buffers do not need to be in DMA memory and they can also be placed in internal memory so LVGL will be able to render faster. I want to confirm what I believe the problem is. I think I need to reduce the y axis by one or 2 lines. Are you rotating the screen at all? or is this happening with zero rotation? |
Beta Was this translation helpful? Give feedback.
-
|
IDK why I asked about the rotation. I am able to see it right in front of me that you are not using any rotation. |
Beta Was this translation helpful? Give feedback.
-
|
The result is the same with DMA, without DMA, and with Internal or PSRAM. Only if the Fullframe buffer, works without artifacts. |
Beta Was this translation helpful? Give feedback.
-
|
I am testing with a Waveshare 4in 480x480 LCD w ST7701 and see the same behavior as @straga regarding the buffers. I'm using display.init(13) for this display. |
Beta Was this translation helpful? Give feedback.
-
|
OK so there is an issue I have to sort out with the RGB driver and a line being added I will look into it shortly. This would be easier if someone was able to test at the time I was making changes. |
Beta Was this translation helpful? Give feedback.
-
|
I am available to test. |
Beta Was this translation helpful? Give feedback.
-
|
OK cool. Let me go and take a quick look see at it and i might be able to get it sorted out quickly. It looks like it is adding an extra line so I am going to shorten up the copy that takes place to the fill buffer.. If you can confirm one things for me. does it do it for all rotations, 90, 180 and 270 or only some of them?,, |
Beta Was this translation helpful? Give feedback.
-
|
I made a change so you can test it if you like. could be a simple fix. we shall soon find out. |
Beta Was this translation helpful? Give feedback.
-
|
First update is without your changes I am not seeing the artifact with these settings Possibly from changing init(type=6) to init(type=13) , which fixed colors. Rotation doesn't seem to work well Doing display.set_rotation(0) no change |
Beta Was this translation helpful? Give feedback.
-
|
With original (yesterday) build, I am still getting artifact at 1/20th |
Beta Was this translation helpful? Give feedback.
-
|
Tested the version with y_end+=1; commented out. Artifacts are still there with //20. Rotation 90 looks different, has these horizontal lines.
|
Beta Was this translation helpful? Give feedback.
-
|
I've been looking for a driver for the st7701 as well and just found one at https://github.com/DFRobot-Embedded-Software/Waveshare_LVGL_Micropython/tree/master/api_drivers/common_api_drivers/display/st7701. I don't know anything about it but thought I'd point it out in case it was helpful. |
Beta Was this translation helpful? Give feedback.
-
|
thank you for pointing out that library. They are actually using my code against the licensing of this project. I have opened an issue on their repo to give notice that they need to correct their licensing issues. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @kdschlosser, I took a video of the display, so you can see the remaining issues. These are unlisted youtube videos... |
Beta Was this translation helpful? Give feedback.
-
|
OK you have a lot going on with those videos and I am not sure how to make heads or tales of what is going on. Without seeing any of the code you are running it is going to be difficult to diagnose what is happening. The same mechanics that are used for the st77701 display you are using are the same mechanics used for a typical RGB display except for the SPI3 wire for setting parameters for the display. A typical RGB display I have not heard of anyone having any issues with the driver so I am under the assumption it is working like it should be. Since you are able to see something on your display means the SPI3wire is working properly. That would leave the init commands to be what the problem is. You will need to locate the init drivers for your specific display and you will need to code in the init sequence. That is where I would start off at is making sure those init commands are correct for your specific display. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @kdschlosser, I have read every comment on this thread before beginning, in order to do my best in getting up to speed. I will post my code last, but here are my assumptions. Please tell me where my logic or understanding is incorrect:
Since my first comment, I have done some further testing. Here are my additional observations:
I created a some further tests, by just drawing a 1 pixel rectangle around the perimeter of the screen. If I draw a rectangle on a display with zero degrees rotation, I see a rectangle. If I set rotation to 90, 180 or 270 degrees, one of the sides is missing. This says to me that there is a bug in the display rotation code. My gut says that the loop iteration is stopping one short, but I'd have to check. Here are some screenshots. Maybe I'll take a look at the code and see if I can spot the problem to save you some time. I have drawn a blob in the x=0, y=0 corner, for my own sanity... 
All my tests begin with the following code, borrowed from earlier in this discussion: from micropython import const # NOQA
# Full frame size for 4 inch display
WIDTH = const(480)
HEIGHT = const(480)
# Full frame buffer option
# BUFFER_SIZE = int(WIDTH * HEIGHT * 2) # 2 bytes per pixel for RGB565
# 1/20th of the full frame
BUFFER_SIZE = int(WIDTH * HEIGHT * 2 // 20) # 2 bytes per pixel for RGB565
import lcd_bus # NOQA
display_bus = lcd_bus.RGBBus(
hsync=16,
vsync=17,
de=18,
pclk=21,
# B
data0=4,
data1=5,
data2=6,
data3=7,
data4=15,
# G
data5=8,
data6=20,
data7=3,
data8=46,
data9=9,
data10=10,
# R
data11=11,
data12=12,
data13=13,
data14=14,
data15=0,
freq=12000000,
hsync_pulse_width=8,
hsync_back_porch=20,
hsync_front_porch=10,
vsync_pulse_width=8,
vsync_back_porch=10,
vsync_front_porch=10
)
from spi3wire import Spi3Wire
spi3wire = Spi3Wire(
scl=48,
sda=47,
cs=39,
freq=500000 #76 Гц
)
spi3wire.init(8, 8) # cmd_bits=8, param_bits=8
import st7701
import lvgl as lv # NOQA
fb1 = display_bus.allocate_framebuffer(BUFFER_SIZE, lcd_bus.MEMORY_SPIRAM) # Use PSRAM for LVGL buffer too
fb2 = display_bus.allocate_framebuffer(BUFFER_SIZE, lcd_bus.MEMORY_SPIRAM) # Use PSRAM for LVGL buffer too
display = st7701.ST7701(
display_bus,
spi3wire,
WIDTH,
HEIGHT,
frame_buffer1=fb1,
frame_buffer2=fb2,
backlight_pin=38,
color_space=lv.COLOR_FORMAT.RGB565,
rgb565_byte_swap=False,
bus_shared_pins=False
)
print('Hello LCD')
display.set_power(True)
display.init(type=9)
display.set_backlight(100)
import gt911
import i2c
i2c_bus = i2c.I2C.Bus(host=1, scl=45, sda=19, freq=100000)
touch_i2c = i2c.I2C.Device(i2c_bus, gt911.I2C_ADDR, gt911.BITS)
indev = gt911.GT911(touch_i2c, debug=False)
import time
def create_line(colour, start, end, width=1):
# 1. Create a Line Object
line_style = lv.style_t()
line_style.init()
line_style.set_line_width(width)
line_style.set_line_color(colour)
# Define the vertical line points (x1, y1) to (x2, y2)
# We keep X at 0 initially; the animation will move the object's X coordinate
line_points = [lv.point_precise_t({'x': start[0], 'y': start[1]}), lv.point_precise_t({'x': end[0], 'y': end[1]})]
line = lv.line(lv.screen_active())
line.set_points(line_points, 2)
line.add_style(line_style, 0)
return line
def rectangle(colour, line_width=1):
create_line(lv.color_hex(colour), ( 0, 0), ( 0, 479), width=line_width)
create_line(lv.color_hex(colour), ( 0, 479), (479, 479), width=line_width)
create_line(lv.color_hex(colour), (479, 479), (479, 0), width=line_width)
create_line(lv.color_hex(colour), (479, 0), ( 0, 0), width=line_width)Testing with sliders, I add this: def slider_test():
scrn = lv.screen_active()
scrn.set_style_bg_color(lv.color_hex(0xFF0000), 0)
slider = lv.slider(scrn)
slider.set_size(400, 50)
slider.center()
slider2 = lv.slider(scrn)
slider2.set_size(80, 400)
slider2.center()
label = lv.label(scrn)
label.set_text('HELLO WORLD!')
label.align(lv.ALIGN.CENTER, 0, -50)
import task_handler
th = task_handler.TaskHandler()
i=0
try:
while True:
time.sleep_ms(10000)
except Exception as e:
print('Error occurred: ', e)
except KeyboardInterrupt:
print('Program Interrupted by the user')Testing with an animation, I add variations of this, depending on how many lines (1 to 3) that I want: def anim_test():
scrn = lv.screen_active()
scrn.set_style_bg_color(lv.color_hex(0x1F1F1F), 0)
label = lv.label(scrn)
label.set_text('HELLO WORLD!')
label.center()
LINE_WIDTH = 50
# line = create_line(lv.color_hex(0x00FF00), (0, 0), (480, 0), width=LINE_WIDTH)
line2 = create_line(lv.color_hex(0xFFFFFF), (0, 0), ( 0, 479), width=LINE_WIDTH)
# line3 = create_line(lv.color_hex(0xFF0000), (0, 0), (480, 480), width=LINE_WIDTH)
def anim_cb(a, v):
# line.set_y(v)
line2.set_x(v)
# line3.set_points([lv.point_precise_t({'x': v-200, 'y': v+200}), lv.point_precise_t({'x': v+200, 'y': v-200})], 2)
anim = lv.anim_t()
anim.init()
anim.set_var(line2)
anim.set_values(0 + LINE_WIDTH // 2, 479 - LINE_WIDTH // 2)
anim.set_duration(4000)
anim.set_reverse_duration(4000)
anim.set_repeat_count(lv.ANIM_REPEAT_INFINITE)
anim.set_custom_exec_cb(anim_cb)
lv.anim_t.start(anim)
import task_handler
th = task_handler.TaskHandler()
i=0
while True:
time.sleep_ms(4000)
i = (i+1) % 4
if i == 0:
rotation = lv.DISPLAY_ROTATION._0
elif i == 1:
rotation = lv.DISPLAY_ROTATION._90
elif i == 2:
rotation = lv.DISPLAY_ROTATION._180
else:
rotation = lv.DISPLAY_ROTATION._270
display.set_rotation(rotation)
label.set_text(f'Rotation: {i * 90} degrees')Testing with rectangles, I add this: def rectangle_test():
scrn = lv.screen_active()
scrn.set_style_bg_color(lv.color_hex(0x1F1F1F), 0)
label = lv.label(scrn)
# label.set_text('HELLO WORLD!')
label.center()
import task_handler
th = task_handler.TaskHandler()
i=0
while True:
i = (i+1) % 4
if i == 0:
rotation = lv.DISPLAY_ROTATION._0
colour = 0xFF0000
elif i == 1:
rotation = lv.DISPLAY_ROTATION._90
colour = 0x00FF00
elif i == 2:
rotation = lv.DISPLAY_ROTATION._180
colour = 0x0000FF
else:
rotation = lv.DISPLAY_ROTATION._270
colour = 0xFFFFFF
display.set_rotation(rotation)
label.set_text(f'Rotation: {i * 90} degrees')
rectangle(colour, line_width=1)
time.sleep_ms(1000)This is what I created the screenshots with. It highlights the edge cases without any animation. So you must alter the def rectangle_test_2():
scrn = lv.screen_active()
scrn.set_style_bg_color(lv.color_hex(0x1F1F1F), 0)
label = lv.label(scrn)
label.center()
import task_handler
th = task_handler.TaskHandler()
DEGREES=90
if DEGREES == 0:
rotation = lv.DISPLAY_ROTATION._0
elif DEGREES == 90:
rotation = lv.DISPLAY_ROTATION._90
elif DEGREES == 180:
rotation = lv.DISPLAY_ROTATION._180
else:
rotation = lv.DISPLAY_ROTATION._270
display.set_rotation(rotation)
label.set_text(f'Rotation: {DEGREES} degrees')
colour = 0xFFFFFF
create_line(lv.color_hex(colour), ( 0, 0), ( 0, 479))
create_line(lv.color_hex(colour), ( 0, 479), (479, 479))
create_line(lv.color_hex(colour), (479, 479), (479, 0))
create_line(lv.color_hex(colour), (479, 0), ( 0, 0))
create_line(lv.color_hex(colour), (4, 4), (4, 9))
create_line(lv.color_hex(colour), (4, 9), (9, 9))
create_line(lv.color_hex(colour), (9, 9), (9, 4))
create_line(lv.color_hex(colour), (9, 4), (4, 4))
while True:
time.sleep_ms(1000)Then I choose which to run at the end: # slider_test()
# anim_test()
# rectangle_test()
rectangle_test_2() |
Beta Was this translation helpful? Give feedback.
-
|
Hi @kdschlosser, I've found the bug. It is in the driver. It relates to mixing end-inclusive and end-exclusive co-ordinate systems in the With my updates, I no longer get any artifacts with rotation=0 or missing lines of pixels with rotation=[90, 180, 270]. The reason that the rotate 0 behaves differently to the 90, 180 and 270 is because 'rotate 0' uses end inclusive co-ordinates and '90, 180 and 270' mostly assume end exclusive co-ordinates, with a couple of hacks to get it working, that could be removed, once the co-ordinates were standardised. Since I have no experience of this code, I turned on debug and then confirmed the standard used in the tx_color calls: This is quite lengthy to explain here in a comment, so let me know if you would like a pull request. But anyway, here are the mods I made. Caveat: I have only modified and tested 16-bit non-dithered operations. Equivalent changes would be required for other formats. It is also quite possible that I have missed some cases. Happy to discuss or test further - I'm only doing this for fun and to exercise my brain a bit! First, I modified the end co-ordinates to always be end-exclusive, since most of your code already operates that way. void copy_pixels(void *dst, void *src, uint32_t x_start, uint32_t y_start,
uint32_t x_end, uint32_t y_end, uint32_t dst_width, uint32_t dst_height,
uint32_t bytes_per_pixel, uint8_t rotate, uint8_t rgb565_dither)
{
// Be consistent with using end exclusive co-ordinates
x_end += 1;
y_end += 1;
// Now...
// start points should always be compared with width/height -1
// end points should be compared with width/height
if (rotate == RGB_BUS_ROTATION_0) {
rotate0(src, dst, MIN(x_start, dst_width-1), MIN(y_start, dst_height-1),
MIN(x_end, dst_width), MIN(y_end, dst_height),
dst_width, dst_height, bytes_per_pixel, rgb565_dither);
} else {
// Remove hack
// y_end += 1; // removes black lines between blocks
if (rotate == RGB_BUS_ROTATION_90 || rotate == RGB_BUS_ROTATION_270) {
x_start = MIN(x_start, dst_height-1); // tweak
x_end = MIN(x_end, dst_height);
y_start = MIN(y_start, dst_width-1); // tweak
y_end = MIN(y_end, dst_width);
} else {
x_start = MIN(x_start, dst_width-1); // tweak
x_end = MIN(x_end, dst_width);
y_start = MIN(y_start, dst_height-1); // tweak
y_end = MIN(y_end, dst_height);
}
if (bytes_per_pixel == 1) {
rotate_8bpp(src, dst, x_start, y_start, x_end, y_end, dst_width, dst_height, rotate);
} else if (bytes_per_pixel == 2) {
rotate_16bpp(src, dst, x_start, y_start, x_end, y_end, dst_width, dst_height, rotate, rgb565_dither);
} else if (bytes_per_pixel == 3) {
rotate_24bpp(src, dst, x_start, y_start, x_end, y_end, dst_width, dst_height, rotate);
} else if (bytes_per_pixel == 4) {
rotate_32bpp(src, dst, x_start, y_start, x_end, y_end, dst_width, dst_height, rotate);
}
}
}I had to modify rotate0 to use end exclusive co-ordinates, as that was the standard I chose: void rotate0(uint8_t *src, uint8_t *dst, uint32_t x_start, uint32_t y_start,
uint32_t x_end, uint32_t y_end, uint32_t dst_width,
uint32_t dst_height, uint8_t bytes_per_pixel, uint8_t rgb565_dither)
{
dst += ((y_start * dst_width + x_start) * bytes_per_pixel);
if(x_start == 0 && x_end == (dst_width - 1) && !rgb565_dither) {
// memcpy(dst, src, dst_width * (y_end - y_start + 1) * bytes_per_pixel);
// Change to end exclusive
memcpy(dst, src, dst_width * (y_end - y_start) * bytes_per_pixel);
} else {
// uint32_t src_bytes_per_line = (x_end - x_start + 1) * bytes_per_pixel;
// Change to end exclusive
uint32_t src_bytes_per_line = (x_end - x_start) * bytes_per_pixel;
uint32_t dst_bytes_per_line = dst_width * bytes_per_pixel;
if (rgb565_dither) {
for(uint32_t y = y_start; y < y_end; y++) {
for (uint32_t x=0;x<x_end;x++) {
rgb565_dither_pixel(CALC_THRESHOLD(x, y), (uint16_t *)(src) + x);
copy_16bpp((uint16_t *)(src) + x, (uint16_t *)(dst) + x);
}
dst += dst_bytes_per_line;
src += src_bytes_per_line;
}
} else {
for(uint32_t y = y_start; y < y_end; y++) {
memcpy(dst, src, src_bytes_per_line);
dst += dst_bytes_per_line;
src += src_bytes_per_line;
}
}
}
}Next, I updated rotate_16bpp... void rotate_16bpp(uint16_t *src, uint16_t *dst, uint32_t x_start, uint32_t y_start,
uint32_t x_end, uint32_t y_end, uint32_t dst_width, uint32_t dst_height,
uint8_t rotate, uint8_t rgb565_dither)
{
uint32_t i;
uint32_t j;
// uint32_t src_bytes_per_line = x_end - x_start + 1;
// Change to end exclusive
// Also, this variable is not well named. It is really src_uint16s_per_line. See copy_16bpp call pointer arithmetic.
uint32_t src_bytes_per_line = x_end - x_start;
uint32_t offset = y_start * src_bytes_per_line + x_start;
if (rgb565_dither) {
switch (rotate) {
case RGB_BUS_ROTATION_90:
for (uint32_t y = y_start; y < y_end; y++) {
for (uint32_t x = x_start; x < x_end; x++) {
i = y * src_bytes_per_line + x - offset;
j = (dst_height - 1 - x) * dst_width + y;
rgb565_dither_pixel(CALC_THRESHOLD(x, y), src + i);
copy_16bpp(src + i, dst + j);
}
}
break;
// MIRROR_X MIRROR_Y
case RGB_BUS_ROTATION_180:
LCD_UNUSED(j);
LCD_UNUSED(src_bytes_per_line);
LCD_UNUSED(offset);
for (uint32_t y = y_start; y < y_end; y++) {
i = (dst_height - 1 - y) * dst_width + (dst_width - 1 - x_start);
for (uint32_t x = x_start; x < x_end; x++) {
rgb565_dither_pixel(CALC_THRESHOLD(x, y), src);
copy_16bpp(src, dst + i);
src++;
i--;
}
src++;
}
break;
// SWAP_XY MIRROR_X
case RGB_BUS_ROTATION_270:
for (uint32_t y = y_start; y < y_end; y++) {
for (uint32_t x = x_start; x < x_end; x++) {
i = y * src_bytes_per_line + x - offset;
j = (x * dst_width + dst_width - 1 - y);
rgb565_dither_pixel(CALC_THRESHOLD(x, y), src + i);
copy_16bpp(src + i, dst + j);
}
}
break;
default:
LCD_UNUSED(i);
LCD_UNUSED(j);
LCD_UNUSED(src_bytes_per_line);
LCD_UNUSED(offset);
break;
}
} else {
switch (rotate) {
case RGB_BUS_ROTATION_90:
for (uint32_t y = y_start; y < y_end; y++) {
for (uint32_t x = x_start; x < x_end; x++) {
i = y * src_bytes_per_line + x - offset;
j = (dst_height - 1 - x) * dst_width + y;
copy_16bpp(src + i, dst + j);
}
}
break;
// MIRROR_X MIRROR_Y
case RGB_BUS_ROTATION_180:
LCD_UNUSED(j);
LCD_UNUSED(src_bytes_per_line);
LCD_UNUSED(offset);
for (uint32_t y = y_start; y < y_end; y++) {
i = (dst_height - 1 - y) * dst_width + (dst_width - 1 - x_start);
for (uint32_t x = x_start; x < x_end; x++) {
copy_16bpp(src, dst + i);
src++;
i--;
}
// Hey, I needed that pixel!!!
// src++;
}
break;
// SWAP_XY MIRROR_X
case RGB_BUS_ROTATION_270:
for (uint32_t y = y_start; y < y_end; y++) {
for (uint32_t x = x_start; x < x_end; x++) {
i = y * src_bytes_per_line + x - offset;
j = (x * dst_width + dst_width - 1 - y);
copy_16bpp(src + i, dst + j);
}
}
break;
default:
LCD_UNUSED(i);
LCD_UNUSED(j);
LCD_UNUSED(src_bytes_per_line);
LCD_UNUSED(offset);
break;
}
}
} |
Beta Was this translation helpful? Give feedback.
-
|
I have an RGB display that I can test with. I have not changed the RGB code in a long time and it was working in the past without any issues. I am not sure as to why it would all of a sudden be having an issue in the driver. I suspect that the changes are going to break things for other displays. I will need to test it to see if that is the case. I would need to go back and look at what the driver is doing to be sure. I can see one thing right out of the gate in your code that you should not be doing and that is calling the I see you have 2 different buffer schemes in your code and you are not specific about which one is being used in your videos or for any of the screen shots. To keep everything on the same baseline it is better if you don't allocate any frame buffers and let the driver handle doing that. That will keep everything on the same field when testing. I can also see in your code changes that there is something wrong. see here..
if we assume that the source is a buffer that holds exactly 1 line of pixel data and that line is the absolute first line on the display the coordinates fed in would be we know the width and height of your display is 480 x 480 and you are using RGB565 so the following holds true... Now lets evaluate the memcpy you have in place... and that evaluates to ZERO bytes copied. What the results should be is 960 if you take a look here the same thing comes up.. That means the number of pixels in a single line of the source buffer. If the buffer is a full buffer the number of pixels is calculated as x_end - x_start + 1. If x_start = 0 and x_end = 479 by removing that +1 you end up loosing a pixel. I believe there is still something wrong with your display init command because for whatever reason the display is not writing the data where it needs to. There is a bridge IC on your display and that bridge IC needs to be instructed very specifically on how it is supposed to be passing the data along to the display. The changes you have made is not going to work correctly |
Beta Was this translation helpful? Give feedback.
-
I did read through this entire discussion and couldn't see that anyone had actually confirmed everything was fully working.
I just used the code that was being listed further up the discussion.
Bear in mind that the first mod I made was to modify the end co-ordinates to be end exclusive. This effectively nullifies the changes you mention above that are in the end inclusive code. I needed to do this because some of your code assumed end inclusive and some assumed end exclusive. This is why you needed to add in the void copy_pixels(void *dst, void *src, uint32_t x_start, uint32_t y_start,
uint32_t x_end, uint32_t y_end, uint32_t dst_width, uint32_t dst_height,
uint32_t bytes_per_pixel, uint8_t rotate, uint8_t rgb565_dither)
{
// Be consistent with using end exclusive co-ordinates
x_end += 1;
y_end += 1;Here is some of your code for 90 degree rotation. Note the for loop condition. If you pass in case RGB_BUS_ROTATION_90:
for (uint32_t y = y_start; y < y_end; y++) {
for (uint32_t x = x_start; x < x_end; x++) {
i = y * src_bytes_per_line + x - offset;
j = (dst_height - 1 - x) * dst_width + y;
rgb565_dither_pixel(CALC_THRESHOLD(x, y), src + i);
copy_16bpp(src + i, dst + j);
}
}
break;
Again, I have the same display as @straga (Guition 4848S040) and just used his code listed further back. I think the easiest way to see if your display exhibits the same issue is the following:
|
Beta Was this translation helpful? Give feedback.
-
|
By the way, I think this is a great little touchscreen display. And because of the way @kdschlosser has implemented the driver, there is absolutely no screen tearing. For anyone who is interested, here is a link to the device. Where I live, this is cheaper than a nice burger and chips (fries)! |
Beta Was this translation helpful? Give feedback.
-
|
That was actually the really hard thing to do while keeping the performance up as high as possible. Having LVGL manage the copying of buffer data and also the rendering all on one core would kill the update speed big time. The way it is set up is so that the buffer synchronization as well as software rotation is able to be done without causing it to get miserable in terms of update speed. The interrupts for the display to reload the DMA buffer are also moved to the other core so they don't interrupt the rendering at all. If the partial frame buffers are small enough to fit into internal RAM there will be an increase in the rendering speed. In your case they will fit into internal memory and that is where you should place them. You want to tweak the size of the buffers depending on the average amount of real estate on the display that you update at once. If you have a lot of things changing all at once and very often you will want those partial buffers to be larger in size. |
Beta Was this translation helpful? Give feedback.
-
|
Well we all appreciate the work you have put in. Anyone who doesn't just doesnt understand the magnitude of the task! |
Beta Was this translation helpful? Give feedback.
-
|
I'm not trying to toot my own horn or anything like that but I will say that the way I have the RGB driver written makes it possibly the fastest one in written for the ESP32. The overall design of the bus drivers and the higher level display drivers is actually quite elegant. Making it all work at runtime instead of compile time (which is what most display libraries are) and doing it in a manner where a single display driver is able to work across the different bus types was the secret sauce and not the easiest thing in the world to do. The extra layer of doing it in a manner that uses the least possible resources like memory was an added challenge which is why you see the initialization commands done like they are. In MicroPython there are several layers of memory use. The first one being the lexer for the Python code, another being where the module and then you have what gets allocated on the stack from a module. If you delete an imported module that doesn't free up all of the memory that was used by that module. It needs to be explicitly deleted everywhere and then it will free the memory. Some of the init's for a display can be really long so making sure all of the commands are on the stack means it will get GC'd correctly. The second part of it is the use of I think I did a pretty decent job. There are still some glitches that need to be ironed out sure. But for the most part it's stable and it works. Displays are a hard thing to work with. People do not understand that when they buy a display that uses a specific IC and then buy another that is identical in color depth and resolution using the same IC things can be very different in what needs to get done to make it work. The panel is what causes that. The display panel even tho it might be the same color depth and resolution could be made by a different company even if the "display" is the same manufacturer and model number the panel could be made by a different company and that might cause settings to need to be different. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Is it relevant to write a driver for ST7701 ?
If the SPI is just used in initialization LCD, will be possible to write a command initialization and then use parallel RGB driver?
https://focuslcds.com/journals/application-notes/3-wire-spi-parallel-rgb-interface/
The 3-wire Serial Peripheral Interface (SPI) and the 16/18/24-bit RGB parallel interface are used in a sequence to communicate data to the display. The SPI interface is first used to initialize the display parameters through command registers. Once initialized, the display can receive data over the RGB parallel interface at a higher speed. This data can be sent in segments of 16, 18 or 24-bit lengths depending on what is specified by the SPI initialization commands.
Beta Was this translation helpful? Give feedback.
All reactions