from lcd_bus import RGBBus
display_bus = RGBBus(
hsync=41,
vsync=42,
de=2,
disp=-1,
pclk=1,
data0=11, #r0
data1=10, #r1
data2=9, #r2
data3=46, #r3
data4=3, #r4
data5=48, #g0
data6=47, #g1
data7=21, #g2
data8=14, #g3
data9=13, #g4
data10=12, #g5
data11=40, #b0
data12=39, #b1
data13=38, #b2
data14=0, #b3
data15=45, #b4
freq=25000000,
hsync_pulse_width=2,
hsync_front_porch=46,
hsync_back_porch=44,
hsync_idle_low=False,
vsync_pulse_width=2,
vsync_front_porch=16,
vsync_back_porch=18,
vsync_idle_low=False,
pclk_active_neg=False,
pclk_idle_high=False,
de_idle_high=False,
num_fbs=1,
bb_size_px=0,
bb_inval_cache=False,
fb_in_psram=True,
no_fb=False,
disp_active_low=False,
refresh_on_demand=False,
)
disp = lv.display_create(720, 720)
disp.set_color_format(lv.COLOR_FORMAT.RGB565)
display_bus.init(720, 720, 16, buffer_size=720 * 720 * 2, rgb565_byte_swap=False)
buf_1 = display_bus.get_frame_buffer(1)
disp.set_draw_buffers(buf1, None, len(buf1), lv.DISPLAY_RENDER_MODE.FULL)
def tx_done():
disp.flush_ready()
display_bus.register_callback(tx_done)
def flush(_, area, color_p):
x1 = area.x1
x2 = area.x2
y1 = area.y1
y2 = area.y2
size = (x2 - x1 + 1) * (y2 - y1 + 1) * 2
data_view = color_p.__dereference__(size)
data_bus.tx_color(0x00, data_view, x1, y1, x2, y2)
data_bus.register_callback(flush)
The reason why it was failing is you were trying to allocate 2mb of memory into the SRAM which is only 350K or so. That’s not going to work. You should be able to get it running using the example above. Or something close to it anyhow. Get it running using a single buffer first and then try 2 frame buffers. The buffers are going to have to be created in psram as there is simply not going to be enough space in SRAM.
I m setting the pixel clock to 25Mhz because that is what should be achievable. The SPIFLASH and the SPIRAM both share the same SPI bus. That bus is going to be moving along at 80mhz. but since you have to share it between the flash and the ram you could end up with problems if you don’t trim back the speed in which the data is going to be read from the memory especially if you end up collecting something from the flash memory while a dma transfer is going on.
It’s all simple math and it is going to depend on the number of lanes you have attached to the display and also the number of lanes being used for the spiram. If you have octal spiram there are 8 lanes available. if you have quad flash only 4 of those 8 lanes are shared. if you have octal flash than all 8 are shared. So account for that when setting the pixel clock frequency. It has to be balanced against the number of lanes being used for the display. You don’t want to be trying to collect bytes from memory faster than it can be done. that will lead to tearing of the display data. so set the clock accordingly. The 25Mhz is a good number for a 16 lane RGB connection using octal spiram and quad flash. If you have 24 lanes connected then you will want to lower that pixel clock to probably 20mhz maybe lower.
so if you have 24 lanes of display requesting 24 bytes of memory all at the same time from an octal SPI bus you will not be able to have the pixel clock set to 80mhz. you will overrun the ability to collect the bytes from memory.
You probably already know the above information and it is more for the folks that don’t know. I know you had yours set at a safe 16mhz and you can leave it there and once you get it running dial it up until you get pixel anomalies.
