|
Post by johnleung on Oct 8, 2018 3:38:30 GMT -8
Hi I am working on a project to use an off-the-shelf mipi display from smart phone with FT810. This mipi display has a resolution of 480*854 with 2 mipi lanes. The progress is that simple demo of hello world, widgets, and sprites can run. Below is a picture showing widgets demo. A short video is available from dropbox for another demo running sprites.ino (included in GD2 library for Arduino): www.dropbox.com/s/t9jfuc2vjueg1i7/VID_20181008_161630.mp4?dl=0www.dropbox.com/s/t9jfuc2vjueg1i7/VID_20181008_161630.mp4?dl=0Because the standard demo is designed for 480*272 resolution, it turns out that only the upper half of the display is being used. From the video you can see that I have changed the overlay text to lower half but I cannot change the sprites' circling center. Does anyone know how to modify the sprites demo included in Arduino gd2 library so that the whole screen is used for sprites? Another concern is that, FT81x is able to support 800*480 therefore its GRAM should be enough for 480*854, is it correct? Any suggestion is welcome. John
|
|
|
Post by jamesbowman on Oct 8, 2018 10:44:47 GMT -8
Wow, nice display!
Normally inside GD.begin(), it also sets the variables GD.w and GD.h to the width and height of the display. Some of the demos are written to work properly with any GD.w and GD.h - they're resolution independent.
I think currently only helloworld, fizz and sketch are resolution independent.
If you set them after GD.begin() like this:
GD.w = 480; GD.h = 854; Then these demos should work better. Please post more pictures -- this is quite an interesting new display.
About GRAM, there is 1Mbyte, so a full-screen image is 480*854*2 bytes = 819K So yes you can create a color bitmap covering the whole screen.
|
|
|
Post by johnleung on Oct 9, 2018 8:09:53 GMT -8
Thank you, James. I have tried fizz and helloworld with video as below: fizz- www.dropbox.com/s/j5q8fetqz8ws1f8/VID_20181009_fizz.mp4?dl=0helloworld - www.dropbox.com/s/uelqiuotpkpvrfd/VID_20181009_helloWorld.mp4?dl=0There is a CTP laminated with controller FT6x06. It seems this chip is compatible with FT5x06 which is officially supported by FT81x so I just wired it up by SDA,SCL,RST, and INT. After calibration with cmd_calibrate() REG_TOUCH_TRANSFORM_A ~ F return some meaning values. Surprisingly the CTP works, but a fine tune is required. Screen shot below shows REG_TOUCH_TRANSFORM_x values and raw touch coordinates with GD.inputs.x and GD.inputs.y (GD2 library). The problem is that touch coordinates at top left (0,0) returns something like (-4,19). The question is, how to fine tune it? What is the equation behind (x,y) touch value correlation with REG_TOUCH_TRANSFORM_A ~ F? Any suggestions is welcome. John
|
|
wzwsg
New Member
Posts: 1
|
Post by wzwsg on Oct 16, 2018 0:48:42 GMT -8
|
|
|
Post by jamesbowman on Oct 16, 2018 12:24:59 GMT -8
I think that touch screen calibration returning (-4, 19) for the top-left corner might be actually working fine.
This seems quite a small error for a display with a fine pitch like this.
Does the bottom right corner give coordinates of about (480, 854)?
|
|
|
Post by johnleung on Oct 17, 2018 0:20:26 GMT -8
James, you are right about the voltage level of 1.8V IO. But the CTP controller can tolerant 3.3V (actually up to 3.6V) so at this moment I am using 3.3V to save voltage level translators. A good news is that REG_TOUCH_RAW_XY readings are very beautiful. Touch action at top left corner gives me something like (2,0), top right (478,2), bottom left (2,850), & bottom right (477, 850). It is not exactly (0,0) ~ (479, 853) due to human discrepancy. Trials for three fixed icons close to the lower edge of the smartphone LCD, REG_TOUCH_RAW_XY returns 0xF00384, 0x500384, & 0x1900384. They convert to (x,y) in decimal as (240,900), (80,900), and (400,900). These readings agree exactly what I have got with a direct I2C driver for FT6306 with Arduino. The conclusion is, low level driver is working as expected and FT813's embedded CTP driver can be used for FT6306. Tests above leave me one problem. From a series of careful calibration procedures I've found REG_TOUCH_TRANSFORM_A ~ F return not very stable values. Screen-shot is attached for four passes from Serial Monitor with repeated system reset and calibrations. Below each labeled REG_TOUCH_TRANSFORM_X register values are X,Y coordinates obtained by printing GD.inputs.x and GD.inputs.y with my finger touching top left corner. I must say readings for x,y deviate too much even from the standard of human touches. Up to now what I can say 1. REG_TOUCH_RAW_XY giving expected coordinates and stable results. FT813's embedded CTP driver can be used for FT6306. 2. cmd_calibrate() returns diverse calibration coefficients 3. GD.inputs.x and .y return coordinates deviate from ideal coordinates. Now the next question: Is it possible to bypass cmd_calibrate() and custom-made a calibration routine to make use of REG_TOUCH_RAW_XY with custom GUI to get REG_TOUCH_TRANSFORM_A ~ F? What is/are the hidden equation(s) behind REG_TOUCH_RAW_XY & REG_TOUCH_TRANSFORM_A ~ F? Attachments:
|
|
|
Post by jamesbowman on Oct 17, 2018 9:06:09 GMT -8
Agreed, it looks like manual calibration is making things worse, because the screen is already calib rated.
The six TOUCH_TRANSFORM registers are a 3x2 matrix. The incoming "RAW" (x,y) coordinates are multiplied by this matrix to give the "SCREEN" coordinates.
Each of the six numbers is a signed fixed-point number in S15.16 format.
The actual transformation in the hardware fro raw (x,y) to screen coordinates is something like:
screen_x = (x * _A) + (y * _B) + _C screen_y = (x * _D) + (y * _E) + _F Looking at the numbers you posted, they are very close to the identity matrix. So maybe you can try this:
GD.wr32(REG_TOUCH_TRANSFORM_A, 0x10000); GD.wr32(REG_TOUCH_TRANSFORM_B, 0); GD.wr32(REG_TOUCH_TRANSFORM_C, 0); GD.wr32(REG_TOUCH_TRANSFORM_D, 0); GD.wr32(REG_TOUCH_TRANSFORM_E, 0x10000); GD.wr32(REG_TOUCH_TRANSFORM_F, 0);
This is the identity matrix (1,0,0, 0,1,0), and with this setup the hardware will give the same numbers for RAW X,Y as SCREEN X,Y.
|
|
|
Post by loboris on Oct 17, 2018 12:15:43 GMT -8
Hi I am working on a project to use an off-the-shelf mipi display from smart phone with FT810. This mipi display has a resolution of 480*854 with 2 mipi lanes. ... Could you, please, give more detailes about which display are you using and how have you connected it to the FT810 (hardware) ? I didn't know FT810 can drive mipi displays.
|
|
|
Post by johnleung on Oct 18, 2018 0:46:53 GMT -8
James, thanks a lot, your support is excellent.
GD.wr32(REG_TOUCH_TRANSFORM_A, 0x10000); GD.wr32(REG_TOUCH_TRANSFORM_B, 0); GD.wr32(REG_TOUCH_TRANSFORM_C, 0); GD.wr32(REG_TOUCH_TRANSFORM_D, 0); GD.wr32(REG_TOUCH_TRANSFORM_E, 0x10000); GD.wr32(REG_TOUCH_TRANSFORM_F, 0); This means no calibration is required because 0x10000 and 0 are default values for their individual registers after reset. As a result, I just needed to set CALIBRATION to 0 in GD2.cpp to bypass a second calibration, as you said the CTP is calibrated ex-factory. No need to re-calibrate it, else the performance becomes worse.
Now, after bypassing cmd_calibrate() REG_TOUCH_RAW_XY agrees exactly GD.inputs.x & .y. Stable touches for single points. I will proceed to two fingers to see what's next...
The mipi display is wired to a mipi-bridge chip SSD2828. This chip can drive up to 4 data lanes of FHD resolution (1080*1920) converting RGB video to mipi. The screen I am testing is a 480*854 with CTP laminated. Its resolution fits very well with specifications of FT81x. What surprises me is that the CTP (FocalTech FT6306) can be driven with FT813 directly! Now the preliminary test shows this screen is a "usable" screen for a lot more projects such as DIY smartphones.
SSD2828 information can be obtained from Solomon Systech Ltd. This is the same company in Hong Kong producing many OLED drivers of SSD series...
John
|
|
|
Post by johnleung on Oct 22, 2018 20:27:46 GMT -8
Single touch is working with GD.cmd_sketch(). This is the video in my dropbox: www.dropbox.com/preview/VID_20181023_120945.mp4?role=personalDual touches is working too but GD.cmd_sketch() only work with single touch, I think. Serial.print() for REG_CTOUCH_TOUCH_XY and REG_CTOUCH_TOUCH1_XY shows two fingers are detected but GD.cmd_sketch() only draws either one, not both. Data here capture a part of (x,y) and (x1,y1) from Serial.Monitor, also shows at the video background. x:373 y:653 x1:152 y1:737 x:373 y:660 x1:152 y1:737 x:373 y:667 x1:153 y1:748 x:375 y:683 x1:155 y1:762 x:376 y:691 x1:156 y1:769 x:378 y:719 x1:156 y1:769 x:379 y:723 x1:159 y1:802 x:379 y:727 x1:160 y1:806 x:380 y:731 x1:160 y1:810 Need to customerize this sketch function if dual fingers drawing is required. Below is the Arduino code: #include <EEPROM.h>
#include <SPI.h>
#include <GD2.h>
void setup() //' a{
{
Serial.begin(115200); // JCB
GD.begin(~GD_STORAGE);
//set CTP extended mode
GD.wr32(REG_CTOUCH_EXTENDED, 0x00); //extended mode for dua touches
GD.cmd_memset(0, 0x00, long(GD.w) * GD.h); // clear the bitmap
GD.Clear(); // draw the bitmap
GD.ColorRGB(0xff2030);
GD.cmd_text(GD.w / 2, GD.h / 2, 31, OPT_CENTER, "sketch demo");
GD.BitmapLayout(L8, GD.w, GD.h);
GD.BitmapSize(BILINEAR, BORDER, BORDER, GD.w, GD.h);
GD.Begin(BITMAPS);
GD.ColorRGB(0xff00ff);
GD.Vertex2ii(0, 0);
GD.swap();
GD.cmd_sketch(0, 0, GD.w, GD.h, 0, L8); // start sketching
GD.finish(); // flush all commands
}
void loop() {
static uint32_t pnt1, pnt2;
static uint32_t prev_pnt1;
pnt1 = GD.rd32(REG_CTOUCH_TOUCH_XY);
pnt2 = GD.rd32(REG_CTOUCH_TOUCH1_XY);
if(pnt1!=prev_pnt1){
Serial.print("x:");Serial.print((pnt1>>16)&0xffff, DEC); Serial.print(" ");Serial.print("y:");Serial.print(pnt1&0xffff, DEC);
Serial.print(" ");
Serial.print("x1:");Serial.print((pnt2>>16)&0xffff, DEC); Serial.print(" ");Serial.print("y1:");Serial.println(pnt2&0xffff, DEC);
prev_pnt1 = pnt1;
}
}
|
|
|
Post by jamesbowman on Nov 10, 2018 18:02:25 GMT -8
Hi John,
I just looked up the SSD2828 and it is surprisingly cheap at LCSC. Will you be willing to share your setup code and circuit diagram?
Thanks, J.
|
|
|
Post by johnleung on Nov 14, 2018 3:35:08 GMT -8
No problem. Attached please find few files I have modified from gd2-lib-master to add support for ssd2828. Attachments:wiring.h (8.22 KB)
GD2.cpp (44.57 KB)
GD2.h (39.53 KB)
|
|
|
Post by johnleung on Nov 14, 2018 3:47:15 GMT -8
Also find an untested driver for ssd2828. It is an untested version because I am using some EVK I built for another customer in the past. These files placed in a folder \mipi in the same level as GD2.cpp and GD2.h This EVK convert HDMI to 4-lane mipi with SSD2828. In the first prototype I used this kit with HDMI receiver by-passed. Wiring up with GD3 hardware with 4.3" TFT unplug, and bridge RGB output from 40pin FPC to RGB input of SSD2828. Setup was messy! so I built some PCB with FT813 with header for ESP32 PICO KIT as below. The same GD2 library slightly modified for that. Attachments:hx8379a.h (6.19 KB)
ssd2828.h (4.24 KB)
|
|
|
Post by johnleung on Nov 14, 2018 3:51:49 GMT -8
This is the SSD2828 - HDMI EVK. I have omitted the HDMI part as it is not relevant here. I have bypassed the RGB output from HDMI receiver anyway. The reason I have mentioned using FT81x's GPIO to initialize SSD2828 is an untested version because right now I am still using the proven mbed nxp mcu for init. If you look at SSD2828 datasheet you will find that SPI interface is required only for initialization. Once init is done, it runs with RGB input to covnert to up to 4-lane mipi.
|
|
|
Post by johnleung on Nov 14, 2018 3:55:31 GMT -8
This picture shows the PCB with ESP32 PICO KIT stacking on an adapter then to SSD2828. The left hand side not shown is the MIPI display. This is the mipi display in action. CTP working for dual touch with data send to Serial Monitor OK. But the canned GD.cmd_sketch(0, 0, GD.w, GD.h, 0, L8) drawing fcn of FT81x works for single touch only, which is what I am going to improve it with dual touch.
|
|