Replies: 30 comments 82 replies
-
it doesn't matter if I use the one internally in LVGL or if you use the one built into the ESP-IDF it's still doing the exact same thingn and copying the buffer data pixel by pixel. There is no way around having to do that with an RGB display. an 800 x 480 display connected to the ESP32 is pushing the limits of available resources on the ESP32. If you need to rotate the display as well the update is going to be horribly slow and there is nothing I can do about that. My suggestion is to use a 16 lane I8080 display. that will have GRAM and also hardware rotation so it will perform a lot better and use less memory as well. |
Beta Was this translation helpful? Give feedback.
-
|
thanks for the clarification. It's good to know what type of board would be best, even if you can't always find the winning combo for a given project. Have you ever tested the difference ? Interestingly, I manage to get back to decent performance by doing lots of little things :
your repo is really cool ! |
Beta Was this translation helpful? Give feedback.
-
|
Well, you're doing some pretty amazing things, most of which are beyond me. |
Beta Was this translation helpful? Give feedback.
-
|
I believe that the rotation should be built into LVGL and things should be rendered already rotated as this would not cause only the smallest amount of slow down. It is a very simple thing to handle. Nothing would need to be copied and it would be done when the rendering is done. I am going to ask the head guy directly about this because it is silliness to have to do it after the fact instead of it being done at render time, |
Beta Was this translation helpful? Give feedback.
-
|
OK so I spoke with the head guy over at LVGL. Yes it can be done at rendering time. No it is not currently available. Yes it will drastically improve the performance. No it is not going to be added at this time. He said to add it is a pretty involved and complicated thing to do and the code would be complex and a lot to maintain. He is not against adding it he just has too many thing going on at this point in time. Best I can say at this point is we have to wait and see what happens... I am thinking it is going to be at least a year before it comes up as something to add. I will do my best to get a better way to do it but it is going to require a 3rd frame buffer to make it happen. I can also have it do the rendering on the second core so user code will still be able to run while the rotation is taking place, you will not be able to call the task_handler during this time because the user code will end up getting stalled waiting for the buffer rotation and writing to the display. |
Beta Was this translation helpful? Give feedback.
-
|
We need to try to use 3rd buffer. All C code for rotation do that software after some days of research. Anyway, that is better than nothing. |
Beta Was this translation helpful? Give feedback.
-
|
I am spending some time working on that. This is what I am seeing in my head... LVGL gets a partial buffer, optionally 2. There are 2 full frame buffers and those frame buffers would reside in DMA memory. While one buffer is being written to the display it is also getting copied to the second frame buffer. This is what keeps things in sync. The transmitting happens using DMA so little to no CPU use is involved. core zero will handle copying the transmitting buffer to the idle buffer. This is going to occur while LVGL is rendering to one of the partial buffers which happens on core 1. The only place where a stall may need to be in place is if a partial buffer needs to be written to a frame buffer and the synchronization of the 2 frame buffers is taking place. This will only happen if both partial buffers have been written to by LVGL. one buffer is able to be queued but once the second one needs to get flushed that is when the stall would occur. The copying of the data from the partial buffer to the idle frame buffer happens on core 0 so LVGL is able to keep on going to fill the second partial buffer if there is one. Rotation is going to be done when the partial buffer gets copied to the idle buffer. It's done as a single step so only a single iteration over the partial buffer takes place. Because the partial buffer is well a partial buffer the time it takes to flush a change to the display to the frame buffer is going to be smaller. I wish there was an easy way to dynamically change the frame buffer to using a full size frame buffer in the event that LVGL needs to render the entire screen. That is where performance might suffer ever so slightly but I believe that it is not going to be anything really large in terms of impact due to LVGL being able to write data to a second partial as the first is being copied. The copy process should be a lot faster than the time it takes LVGL to render. I highly doubt that there will be much in the way of the program getting stalled because of copying data from one buffer to the next. The hard part is getting things synchronized properly. LVGL does provide a nice feature where I can check to see if there is more than one partial that needs to be written before swapping the transmitting frame buffers. That's the little nugget that is going to make this all work without having any visual artifacts. |
Beta Was this translation helpful? Give feedback.
-
|
You're heading in the right direction. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Kevin, File "", line 66, in which is very curious |
Beta Was this translation helpful? Give feedback.
-
|
once again without seeing the code you are using it is going to be hard to figure out what is going on. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, it's because it's the same code as before, it worked before the rgb driver changes. This is it : |
Beta Was this translation helpful? Give feedback.
-
|
ok, do this... change this line,... change this... to this... I also have to make a change to the driver as well. I need to set the RGB bus driver so it sets LVGL to use a partial buffer. Give me a bit to do that. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, no error for buffer size now, but sorry i've only black screen with new rgb driver. |
Beta Was this translation helpful? Give feedback.
-
|
OK sorry I think I misunderstood. That code does work on an older version but it doesn't work on the latest. Is that correct? |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I just checked on the old version to make sure it wasn't my code's fault. The new rgb driver crash |
Beta Was this translation helpful? Give feedback.
-
|
does it crash? or does it deadlock? |
Beta Was this translation helpful? Give feedback.
-
|
Deadlock and black screen |
Beta Was this translation helpful? Give feedback.
-
|
I just pushed another commit. It adds some print statement so we can see if it is actually running that copy task and I also changed how the callback is being called so that might make a difference as well. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
something I don't understand, I compiled it like this |
Beta Was this translation helpful? Give feedback.
-
|
This is the correct build command for enabling debugging output. The output is also going to show up in the REPL so you need to have the serial port connected when the ESP32 boots. |
Beta Was this translation helpful? Give feedback.
-
|
also why am I seeing a soft reboot? Soft reboots only clear the ram and not any of the hardware. It causes problems. Always do a hard reset. |
Beta Was this translation helpful? Give feedback.
-
|
I solved the deadlock issue. Tho I am still getting a blank display. I have not checked to see if the code I am using will work with an older version of the binding. If you want to give it a try please do. Remember to make the frame buffers 1/10th the size they used to be. The debugging also works without any issue so I am not sure why you are having a problem with that. |
Beta Was this translation helpful? Give feedback.
-
|
You can go back to using the task handler because the deadlock issue is solved. |
Beta Was this translation helpful? Give feedback.
-
|
thinks are looking up :-) But the screen is black. |
Beta Was this translation helpful? Give feedback.
-
|
About the soft reboot : I use Thonny, it make soft reboot before the script execution. I disconnect the cable before launching. |
Beta Was this translation helpful? Give feedback.
-
|
I found solution for debuging, simply add this line to the head of your c scripts : probably because I need --usb-otg Result: |
Beta Was this translation helpful? Give feedback.
-
|
ok so you are getting some kind of color written to the buffer. I am not sure why it is not filling the entire buffer. It should be. I have triple checked the math on it. I am going to have to mess about with it some more to see what is happening to figure out what is going on. I think I may know what the issue is. I have to double check. |
Beta Was this translation helpful? Give feedback.
-
|
this may have nothing to do with it, but the pixels at the bottom of the screen remind me of something I had when I used the wrong buffer without lvgl with your driver. |
Beta Was this translation helpful? Give feedback.
-
|
no, forget it, in fact the screen displays and clears at the end : IMG_0939.MOV |
Beta Was this translation helpful? Give feedback.
-
|
There are a total of 4 buffers in use if you allocate 2 buffers for LVGL. 2 full buffers and 2 partial buffers. you need to have 2 full buffers when dealing with RGB displays. One that is being sent to the display and the other is being used for writing to. The old RGB driver only used those 2 buffers and LVGL was set to direct mode. In direct mode LVGL is takes with keeping the buffers in sync meaning one buffer needs to be copied to the other. Having to do this in the main application task/thread would completely kill performance. So what I did was offload that work to the other core of the ESP32. this way the application task/thread would not have any slow down. In order to make that work properly another buffer is needed. Using a partial buffer would mean that now LVGL is only going to render the area that has changed but we are able to use 2 buffers because the moving of the data from a partial buffer to the full buffer occurs on the second core so LVGL is able to render to a buffer while a buffer is being copied to a full frame buffer. The full frame buffer get transmitted using DMA so it doesn't use the CPU to do this. |
Beta Was this translation helpful? Give feedback.
-
|
Let me look into it more. |
Beta Was this translation helpful? Give feedback.
-
|
Give it a try again. I fixed the debugging print and I also flip flopped the active and idle buffers. It looks like that is what is happening. I think there is also one other change I have to make. I am going to look at that now. |
Beta Was this translation helpful? Give feedback.
-
|
OK I did need to fix one other issue. I was passing the width and height when passing the full frame buffer to the RGB portion of the esp_lcd component. I needed to be passing the boundaries of the rectangle that is the display. so the start coordinates would have been 0, 0 and I was passing width, height as the end coordinates when it actually needs to be width - 1, height - 1 |
Beta Was this translation helpful? Give feedback.
-
|
I just pushed a commit that fixes another issue I found. I was not properly stalling the copy task when needing to copy the whole frame buffer. Now it should be working properly. I have to really look at the order of the frame buffers initially. It looks like the current one is going to be the first buffer and the second is the idle. The problem that was seen in the video could have been caused by not stalling the copy task until the buffers actually switched. I am going to change back that flip flop. |
Beta Was this translation helpful? Give feedback.
-
|
I've got to go, but I've made a little video of the result, which is promising. IMG_0940.MOV |
Beta Was this translation helpful? Give feedback.
-
|
ok so that's fantastic that you got it to go. what did you change to get it to work? |
Beta Was this translation helpful? Give feedback.
-
|
It's not me, it's your work :-) |
Beta Was this translation helpful? Give feedback.
-
|
It's still getting hung up tho when I run it. I am not sure what is causing it. |
Beta Was this translation helpful? Give feedback.
-
|
since it is working for you how is the speed. It looks really good from that single button press. Have you tried the rotation? |
Beta Was this translation helpful? Give feedback.
-
|
yeah it works (more or less). (i changed a little the ft5x46 for my screen) as you can see from the video, there's something wrong with the partial updates when the button is pressed. |
Beta Was this translation helpful? Give feedback.
-
|
the rotation works!!! IMG_0941.MOV |
Beta Was this translation helpful? Give feedback.
-
|
oh ! its works this is debugging not disabled. i 'm compressing the video... |
Beta Was this translation helpful? Give feedback.
-
|
sorry for the light.... |
Beta Was this translation helpful? Give feedback.
-
|
I am not able to watch the video. what did you do to get it working? |
Beta Was this translation helpful? Give feedback.
-
|
Just disabled rgb_bus_event_set(&self->partial_copy) Line to compile because |
Beta Was this translation helpful? Give feedback.
-
IMG_0943.mov |
Beta Was this translation helpful? Give feedback.
-
|
WOooOoOooOo!!! It is fixed!! for Horizontal at least. Still have to test the other rotations. At least we have a start with the rotation being zero. Making some headway with this. YEAH!!!! |
Beta Was this translation helpful? Give feedback.
-
|
I can't wait to test it, I'm compiling lol |
Beta Was this translation helpful? Give feedback.
-
|
With this change it is going to be important to adjust the buffer size that you are allocating. It needs to be adjusted based on how many things are being updated on the display at any given point in time. I am going to add some code that is going to count the number of frame buffers that gets flushed between the last update flag getting passed as True. It will hold an average number for this. the ideal size of the partial buffer is going to be on the cusp of needing 2 flushes per update. You want to keep it to 1 but if the buffer is too large then it is wasting time copying pixels that don't need to be and LVGL is also going to be rendering things that really don't need to be either. I am going to code that in now. It shouldn't be that hard to do. |
Beta Was this translation helpful? Give feedback.
-
|
so cool |
Beta Was this translation helpful? Give feedback.
-
Are you saying that a while true: is out of the question ? |
Beta Was this translation helpful? Give feedback.
-
|
you never want a loop that doesn't end in the main thread. It has to do with the mechanics of MicroPython. There are only a few things where the code will pump for pending scheduled tasks. One of those places is when the REPL prompt is idle. That is the one that is going to get pumped the most often. If you are going to use looping code then start a thread for it. The best way to handle looping code is to create an LVGL timer and when constructing the task_handler.TaskHandler pass the same value you have for the shortest duration timer. I also built into the task_handler.TaskHandler the ability to register callbacks that you can set to get called before lv.task_handler and also after it. Here is an example. scrn = lv.screen_active()
scrn.set_style_bg_color(lv.color_hex(0x000000), 0)
slider = lv.slider(scrn)
slider.set_size(200, 50)
slider.center()
# to set the speed that the task handler runs simply pass a millisecond value to the constructor
# I recommend not going below 10 milliseconds as it tends to flood the CPU with interrupts
# the default value is 33 milliseconds
# th = task_handler.TaskHandler(10)
th = task_handler.TaskHandler()
value = 0
inc = 1
def th_callback(evt_code, user_data):
global value
global inc
if evt_code == task_handler.TASK_HANDLER_STARTED:
value += inc
slider.set_value(value, 0)
if value in (0, 100):
inc = -inc
# return True to have lv.task_handler called and return False to skip calling it.
return True
th.add_event_cb(th_callback, task_handler.TASK_HANDLER_STARTED, None)the above code increases or decreases the slider value once every 33 milliseconds and it doesn't block the main thread to do it. you can update LVGL widgets in this manner because of how the mechanics work and the callback ends up getting called from the main thread through the check that takes place when the REPL is idle. It's kind of pretty cool mechanics actually. Took some thought to get it dialed in right and have LVGL keep accurate time. The reason why you may want to return False is if you called lv.refr_now in the callback for some reason. Or you simply do not want the display to update at that point in time due to needing to process some other code that is more important. |
Beta Was this translation helpful? Give feedback.
-
|
How is it running for you? have you tried the 270 rotation again and did I fix that? |
Beta Was this translation helpful? Give feedback.
-
|
just now Rotation Works (same thing) IMG_0951b.mov |
Beta Was this translation helpful? Give feedback.
-
|
This is 90 |
Beta Was this translation helpful? Give feedback.
-
|
Mine has been running a slider for the last 10 hours and it's working without issue. I have not made any changes since I did the last push to the repo. not sure. I am sure I will find the cause of the issue. |
Beta Was this translation helpful? Give feedback.
-
|
Can you send me your python test code to compare ? |
Beta Was this translation helpful? Give feedback.
-
|
It's for a different display so you will need to adjust the pins and what have you... from micropython import const # NOQA
from i2c import I2C
import gt911
import lcd_bus
import task_handler
import lvgl as lv # NOQA
import rgb_display
_WIDTH = const(800)
_HEIGHT = const(480)
_BUFFER_SIZE = const(76800)
_CTP_SCL = const(9)
_CTP_SDA = const(8)
_CTP_IRQ = const(4)
_SD_MOSI = const(11)
_SD_SCK = const(12)
_SD_MISO = const(13)
_LCD_FREQ = const(13000000)
_HSYNC_PULSE_WIDTH = const(10)
_HSYNC_BACK_PORCH = const(10)
_HSYNC_FRONT_PORCH = const(10)
_VSYNC_PULSE_WIDTH = const(10)
_VSYNC_BACK_PORCH = const(10)
_VSYNC_FRONT_PORCH = const(20)
_PCLK = const(7)
_HSYNC = const(46)
_VSYNC = const(3)
_DE = const(5)
_DISP = None
_BCKL = None
_DRST = None
I2C_BUS = I2C.Bus(
host=1,
scl=_CTP_SCL,
sda=_CTP_SDA,
freq=400000,
use_locks=False
)
TOUCH_DEVICE = I2C.Device(
I2C_BUS,
dev_id=gt911.I2C_ADDR,
reg_bits=gt911.BITS
)
_DATA15 = const(10) # B7
_DATA14 = const(17) # B6
_DATA13 = const(18) # B5
_DATA12 = const(38) # B4
_DATA11 = const(14) # B3
_DATA10 = const(21) # G7
_DATA9 = const(47) # G6
_DATA8 = const(48) # G5
_DATA7 = const(45) # G4
_DATA6 = const(0) # G3
_DATA5 = const(39) # G2
_DATA4 = const(40) # R7
_DATA3 = const(41) # R6
_DATA2 = const(42) # R5
_DATA1 = const(2) # R4
_DATA0 = const(1) # R3
bus = lcd_bus.RGBBus(
hsync=_HSYNC,
vsync=_VSYNC,
de=_DE,
pclk=_PCLK,
data0=_DATA0,
data1=_DATA1,
data2=_DATA2,
data3=_DATA3,
data4=_DATA4,
data5=_DATA5,
data6=_DATA6,
data7=_DATA7,
data8=_DATA8,
data9=_DATA9,
data10=_DATA10,
data11=_DATA11,
data12=_DATA12,
data13=_DATA13,
data14=_DATA14,
data15=_DATA15,
freq=_LCD_FREQ,
hsync_front_porch=_HSYNC_FRONT_PORCH,
hsync_back_porch=_HSYNC_BACK_PORCH,
hsync_pulse_width=_HSYNC_PULSE_WIDTH,
vsync_front_porch=_VSYNC_FRONT_PORCH,
vsync_back_porch=_VSYNC_BACK_PORCH,
vsync_pulse_width=_VSYNC_PULSE_WIDTH,
)
buf1 = bus.allocate_framebuffer(_BUFFER_SIZE, lcd_bus.MEMORY_SPIRAM)
buf2 = bus.allocate_framebuffer(_BUFFER_SIZE, lcd_bus.MEMORY_SPIRAM)
display = rgb_display.RGBDisplay(
data_bus=bus,
display_width=_WIDTH,
display_height=_HEIGHT,
frame_buffer1=buf1,
frame_buffer2=buf2,
color_space=lv.COLOR_FORMAT.RGB565,
rgb565_byte_swap=True
)
display.set_power(True)
display.init()
display.set_backlight(100)
indev = gt911.GT911(TOUCH_DEVICE)
if indev.hw_size != (_WIDTH, _HEIGHT):
fw_config = indev.firmware_config
fw_config.width = _WIDTH
fw_config.height = _HEIGHT
fw_config.save()
del fw_config
# display.set_rotation(lv.DISPLAY_ROTATION._90) # NOQA
scrn = lv.screen_active()
scrn.set_style_bg_color(lv.color_hex(0x000000), 0)
slider = lv.slider(scrn)
slider.set_size(200, 50)
slider.center()
th = task_handler.TaskHandler()
value = 0
inc = 1
def th_callback(*_):
global value
global inc
value += inc
slider.set_value(value, 0)
if value in (0, 100):
inc = -inc
return True
th.add_event_cb(th_callback, task_handler.TASK_HANDLER_STARTED) |
Beta Was this translation helpful? Give feedback.
-
|
ok thanks for your efforts, I'll look at it tomorrow at the office as my screen is tired :-D (in 11 hours compared to you) |
Beta Was this translation helpful? Give feedback.
-
|
It's still getting there tho. Little more work and I think it will work good. |
Beta Was this translation helpful? Give feedback.
-
|
OK so here is an update. Fixed 90° rotation |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys, sorry for entering your discussion but I've been exploring similar issues with rgb_display and rotation for a couple of days. @favnec5 the history is in issue #196. Rotation appears to work, but funnily, if I set it to 90 then I get portrait and mirrored (first pic), with 270 it is okay. But I get these strange horizontal lines which I would attribute to some buffer handling issue on this particular device (Elecrow 5" HMI display). If I set the frame buffers to 1/10 native, then I get 10 stripes. If I set 1/16, it's 16 stripes. I'm now struggling with getting the GT911 to rotate in a similar fashion. When I do _ROTATION = lv.DISPLAY_ROTATION._270 then the active area is scaled down landscape in the upper part of the display area. I found that the coordinate transformation code in I assume that self:_width and _height are the values determined by the touch driver itself, right? But it still is wrong. When I choose _270 for display and touch, the touch active area is rotated by +90° relative to the rotated display, scaled down by about 50% and shifted to the top right. No idea so far what happens here. The coord transformation as such is trivial but there seem to be influences I don't find yet. Lastly (for now - got to leave for a couple of hours) I don't understand why the display content is only displayed after the first tap. Until then, only the textarea cursor area is displayed.
|
Beta Was this translation helpful? Give feedback.
-
|
Sorry - I think the last two messages overlapped. I'll give the last commit some testing later today. |
Beta Was this translation helpful? Give feedback.
-
|
I test last repo, whoouuu it's much more stable ! IMG_0953b.mov |
Beta Was this translation helpful? Give feedback.
-
|
For some reason I am not able to view your movies. You need to convert them to MPEG4 as Apple MOV files are not supported everywhere. I don't know why some of them show and some don't.. As far as the stability is concerned, It should be really rock solid now. I know there is going to need to be some tweaking done to the rotation calculations. If the touch is off that is going to have to be handled by doing a touch calibration. I have to get that running properly. It's on my todo list. I wanted to get this damned RGB driver hammered out before doing that. The performance seems to be pretty good especially when doing the rotations. This is about the best as it is going to get. the only thing that will increase the performance at this point is going to be overclocking the PSRAM. Doing that should give it a decent speed boost. That is the limiting factor at this point. |
Beta Was this translation helpful? Give feedback.
-
|
Yep. The black lines are gone. Display content is immediately shown after boot. 90 / 180 / 270 works as far as orientation, except the pixel calc that Thomas mentioned. The pixel calc gets messed up at _0 as well BTW as soon as I enter text. The character shown is a single "G". Trying to tackle the touch rotation now.
|
Beta Was this translation helpful? Give feedback.
-
|
I forgot to add ... _90 brings up the lines again.
|
Beta Was this translation helpful? Give feedback.
-
|
touch rotation _0 appears to work with display _90 now. (y) |
Beta Was this translation helpful? Give feedback.
-
|
DO NOT change anything in the indev drivers. Leave them be for the time being. That code block you are referencing in the indev driver is not even in use. LVGL handles the touch rotation internally. The GT911 driver works correctly as it is. If the touch is backwards then the code in the RGBBus driver might need to be adjusted. I am pretty sure that I have it set correctly right now there is just the black line in it. But I could be wrong. I am aware of the black lines and my last commit was an attempt to fix it but it didn't. I will get it sorted out. you do not have to set the rotation of the touch driver at all. Make sure you rotate the display AFTER the touch driver is initialized otherwise it may not work properly... Screen rotation is done clockwise. so 90° is when you rotate the display to the right and 270° is to the left. This is how rotation is handled for almost all graphics related stuff. As far as the touch not working correctly. This is not uncommon to have happen. If the manufacturer of the display didn't attach the wires from the touch panel to the IC the way they are supposed to be you can end up with it being mirrored either horizontally, vertically or both, If you are having this problem a touch calibration will fix this issue. |
Beta Was this translation helpful? Give feedback.
-
IMG_0953.mp4This is mp4 Xvid, do you see it ? |
Beta Was this translation helpful? Give feedback.
-
IMG_0953.mp4mp4 / x264 |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
I'd still like to thank you very much, as there's not much left, and the result is impressive in terms of stability. uint16_t copy_bytes_per_line = (x_end - x_start + 1) * (uint16_t)bytes_per_pixel; fixed the problem |
Beta Was this translation helpful? Give feedback.
-
|
yeaaa it works like that : |
Beta Was this translation helpful? Give feedback.
-
|
It can't work like that. There are other cases that use the variable copy_bytes_per_line. so it's not defined for those cases. |
Beta Was this translation helpful? Give feedback.
-
|
I was wrong, just uint16_t copy_bytes_per_line = (x_end - x_start + 1) * (uint16_t)bytes_per_pixel; it works for all. |
Beta Was this translation helpful? Give feedback.
-
|
This is the best for me at this time : ROTATION_0 OK !! very cool !!! |
Beta Was this translation helpful? Give feedback.
-
|
and what about this?? uint32_t src_bytes_per_line = (x_end - x_start) * bytes_per_pixel;
size_t offset = y_start * copy_bytes_per_line + x_start * bytes_per_pixel;
// mp_printf(&mp_plat_print, "x_start=%lu, y_start=%lu, x_end=%lu, y_end=%lu, copy_bytes_per_line=%u, bytes_per_line=%lu, %lu\n",
// x_start, y_start, x_end, y_end, copy_bytes_per_line, bytes_per_line, (uint32_t)((y_start * h_res + x_start) * bytes_per_pixel));
switch (rotate) {
case RGB_BUS_ROTATION_0:
uint8_t *fb = dst + ((y_start * d_width + x_start) * bytes_per_pixel);
if (x_start == 0 && x_end == (d_width - 1)) {
memcpy(fb, src, d_width * (y_end - y_start + 1) * bytes_per_pixel);
} else {
src_bytes_per_line = (x_end - x_start + 1) * bytes_per_pixel;
for (int y = y_start; y < y_end; y++) {
memcpy(fb, src, src_bytes_per_line);
fb += dst_bytes_per_line;
from += src_bytes_per_line;
}
}
break;
// SWAP_XY MIRROR_Y
case RGB_BUS_ROTATION_90:
uint32_t j;
uint32_t i;
for (int y = y_start; y < y_end; y++) {
for (int x = x_start; x < x_end; x++) {
j = y * src_bytes_per_line + x * bytes_per_pixel - offset;
i = ((d_height - 1 - x) * d_width + y) * bytes_per_pixel;
func(dst + i, src + j);
}
}
break;
// MIRROR_X MIRROR_Y
case RGB_BUS_ROTATION_180:
uint32_t index;
for (int y = y_start; y < y_end; y++) {
index = ((d_height - 1 - y) * d_width + (d_width - 1 - x_start)) * bytes_per_pixel;
for (size_t x = x_start; x < x_end; x++) {
func(dst + index, src);
index -= bytes_per_pixel;
from += bytes_per_pixel;
}
}
break;
// SWAP_XY MIRROR_X
case RGB_BUS_ROTATION_270:
uint32_t jj;
uint32_t ii;
for (int y = y_start; y < y_end; y++) {
for (int x = x_start; x < x_end; x++) {
jj = y * src_bytes_per_line + x * bytes_per_pixel - offset;
ii = (x * d_width + d_width - 1 - y) * bytes_per_pixel;
func(dst + ii, src + jj);
}
}
break;
default:
break;
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Is it your last update in your repo? If it is, Nop sorry, I tested, because _90 and _270 need +1 too in src_bytes_per_line (and from is src right ?) |
Beta Was this translation helpful? Give feedback.
-
|
it's true that it's strange that the esp_lcd_rgb_panel.c algorithm doesn't quite work. |
Beta Was this translation helpful? Give feedback.
-
|
Something interesting : y2+1 in display_driver_framwork fixes the _90 and _270 black lines result : perfect :-) |
Beta Was this translation helpful? Give feedback.
-
|
this confirms what I think, it depends on what lvgl provides as output, which is a little different from what espressif has provided in its code. |
Beta Was this translation helpful? Give feedback.
-
|
Based on the last version (where _90, _180, and _270 still have problems but _0 looks good and without lines) I played a bit with the textarea in _0. In the picture you can see little dots below the characters, and these artifacts as I would call them are where the black lines used to be. The dots in the first line are normal dots to demonstrate the difference.
|
Beta Was this translation helpful? Give feedback.
-
|
I'm curious, can you try this in display_driver_framwork.py ? |
Beta Was this translation helpful? Give feedback.
-
|
so, sorry if that didn't make sense. Let me summarize my tests:
There's still _180 that won't work for the time being. everything is staggered. |
Beta Was this translation helpful? Give feedback.
-
|
one last thing, I've just tested the scrolling animation in _90 mode and I can confirm that it works much better than the first full-screen rgb driver :-) |
Beta Was this translation helpful? Give feedback.
-
|
I am happy it is running better now. I knew there was a way to get the RGB driver running better just had to think outside the box to be able to do it. needed to offload the copying to the second core and move the transmitting DMA ISR's to the second core. |
Beta Was this translation helpful? Give feedback.
-
Hi Kevin,
For an other projet, i have a little problem.
This is like in this issue #115
But with pure RGB pannel.
I need to rotate a 4.3" 800x480 RGB screen to 480x800 (90°).
Rgb driver work fine in default 800x480 mode.
I can rotated with lvgl style but... it is very very slow :-(
display.set_rotation(lv.DISPLAY_ROTATION._90) not work (noise on screen)
Are you sure it's not possible to use esp_lcd_panel_swap_xy() / esp_lcd_panel_mirror() into the RGBBus driver to rotate the LCD screen ?
Or maybe you have an idea, for example by inverting x and y in the flush or something else?
regards
Beta Was this translation helpful? Give feedback.
All reactions