Update: Success! Image may be NSFW.
Clik here to view.
I am not sure if the display supports 18-bit color, does it have to have this specified in the datasheet? I have not found anything about it. As you say it would be nice to do the initialization through the Pi's SPI-port, and I probably wouldn't notice the change in color. But anyway:
According to the datasheet the RGB-data will just be ignored before the initialization sequence is done, so it doesn't matter if the RGB-data is sent before that is done. I have been following the timing chart and adjusted the code for the initialization sequence accordingly. I now see that the code I sent previously was very simplified... but I think I now have a lot better understanding of how it works.
The initialization sequence that was in the previously sent datasheet was also for YUV-mode, and not RGB. I have looked online for the sequence for RGB and found it in an earlier revision of the datasheet, who knows why it was removed in the newest version. Luckily it is only 5 commands instead of 154 for YUV:
Image may be NSFW.
Clik here to view.
I have then programmed a Arduino UNO to handle the initialization sequence:
After this was done the display turned on with random lines of color. So I have been attempting to get the timing correctly for the last day, and got it working with these config.txt-lines:
In the datasheet it specifies the typical hbp/vbp as 1, but this gives a very unstable picture with wrong colors. Setting them both to 2 fixed it. Additionally, I had switched hactive and vactive... Now the display works perfectly.
Image may be NSFW.
Clik here to view.
I have tried to adjust the clock-frequency to get a perfect 60Hz, but I do not know how this is calculated. With the current parameters I should get (480+21+24)*(640+40+20)*60=22.05MHz, but setting this in config.txt gives me 59.602Hz. To me it seems it is dependent on the pulse width, as when I have tried to change it and it affects the refresh rate as well. Is there a formula for getting the exact clock-frequency? With clock-frequency=22196265, I get 59.997Hz. And yes, I know that I will not tell the difference, just curious.
Thank you Image may be NSFW.
Clik here to view.
Clik here to view.
I am not sure if the display supports 18-bit color, does it have to have this specified in the datasheet? I have not found anything about it. As you say it would be nice to do the initialization through the Pi's SPI-port, and I probably wouldn't notice the change in color. But anyway:
According to the datasheet the RGB-data will just be ignored before the initialization sequence is done, so it doesn't matter if the RGB-data is sent before that is done. I have been following the timing chart and adjusted the code for the initialization sequence accordingly. I now see that the code I sent previously was very simplified... but I think I now have a lot better understanding of how it works.
The initialization sequence that was in the previously sent datasheet was also for YUV-mode, and not RGB. I have looked online for the sequence for RGB and found it in an earlier revision of the datasheet, who knows why it was removed in the newest version. Luckily it is only 5 commands instead of 154 for YUV:
Image may be NSFW.
Clik here to view.
I have then programmed a Arduino UNO to handle the initialization sequence:
Code:
#include <SPI.h>#define CS_PIN 10 // Chip Select Pin#define MOSI_PIN 11 // Master Out Slave In Pin#define SCK_PIN 13 // Serial Clock Pin#define RESX_PIN 9 // Global Reset Pinuint16_t commands[] = { 0xFD00, // Page 00 0x0200, // Software reset 0x1800, // RGB 24-bit format 0x1995, // VBLK (Default) 0x1A28, // HBLK (Default) 0x0101 // Disable standby mode};void setup() { SPI.begin(); SPI.setBitOrder(MSBFIRST); SPI.setDataMode(SPI_MODE0); pinMode(CS_PIN, OUTPUT); pinMode(RESX_PIN, OUTPUT); digitalWrite(CS_PIN, HIGH); initializeDisplay();}void sendCommand(uint16_t command) { digitalWrite(CS_PIN, LOW); SPI.transfer16(command); digitalWrite(CS_PIN, HIGH);}void initializeDisplay() { digitalWrite(RESX_PIN, HIGH); delay(2); digitalWrite(RESX_PIN, LOW); delay(4); digitalWrite(RESX_PIN, HIGH); delay(11); int numCommands = sizeof(commands) / sizeof(commands[0]); for (int i = 0; i < numCommands; i++) { sendCommand(commands[i]); } delay(10);}void loop() {}Code:
overscan_left=0overscan_right=0overscan_top=0overscan_bottom=0framebuffer_width=640framebuffer_height=480dtparam=spi=offdtparam=i2c_arm=offdtoverlay=vc4-kms-v3ddtoverlay=vc4-kms-dpi-genericdtparam=hactive=640,hfp=20,hsync=2,hbp=40dtparam=vactive=480,vfp=24,vsync=2,vbp=21dtparam=clock-frequency=22196265dtparam=rgb888Image may be NSFW.
Clik here to view.
I have tried to adjust the clock-frequency to get a perfect 60Hz, but I do not know how this is calculated. With the current parameters I should get (480+21+24)*(640+40+20)*60=22.05MHz, but setting this in config.txt gives me 59.602Hz. To me it seems it is dependent on the pulse width, as when I have tried to change it and it affects the refresh rate as well. Is there a formula for getting the exact clock-frequency? With clock-frequency=22196265, I get 59.997Hz. And yes, I know that I will not tell the difference, just curious.
Thank you Image may be NSFW.
Clik here to view.
Statistics: Posted by krstau — Sun Mar 17, 2024 6:54 am
