Jump to content
inakto

Support for STM32F469i-Discovery

Recommended Posts

nquantum   
Quote

Can you tell us what kind of performance you get out of the display? What's the maximum refresh speed you get with your driver/board file?

That a good question! I should ask myself. After think a lot don't know how to measure it! I search from forum  

Quote

 

The refresh of the display is handled by the display controller and is therefore totally incapsulated within the driver. Altering the display refresh rate is done by changing the initialization sequence for the controller.

There is nothing required in ugfx itself to refresh the display. That is actually the whole point in having a display controller - it handles all the refresh for you once you have initialised it.

 

If refresh rate come from initial code in driver then. 

- DSI HOST upto 500Mbits/lane > I use 2 lanes. > 1Gbits total

- I use RGB888 so 24bpp

- LTDC clock is 27.429MHz 

So for DSI HOST 1Gbist/800x480pixelsx24bpp = 108Hz , 

And for LTDC 27.429M/800x480=71.429Hz

>> So if not wrong calculate I should get >60Hz. I think.  Is there a way to verify this?

In case of demo/benchmarks I get error on 

'DWT_CYCCNT' undeclared (first use in this function)

'DWT_CTRL' undeclared (first use in this function)

 

Quote

With regard to the nontouch values, when the surface is not being touched the values are often indeterminate or random depending on the controller hardware. This is of no significance however as the surface is not actually being touched.

Many controllers however also return random or bad values while the sirface is still touched but in the process of the touch lifting. This is much more serioys and the mouse driver has special code to overcome these sorts of problems. 

Another common problem is that controllers that use an external pin to indicate a touch status often have bugs where they in some conditions simply refuse to deassert the pin requiring a full power down to fix. For that and other similar problems we by default  never use the status on those pins. Besides, our z value handling code is much more reliable than the firmware un most touch controllers in determining a proper touched status.

 

Thank you, inmarket. I can see the output onscreen solid and good. That clearly ugfx manage well. 

However I do record clips vdo to more clearly explain. So that you can see if this is normal or not. And you can see in the begining the 2048 value...

clip1

clip2

Please take a look and suggest/comment.

1.jpg

2.jpg

3.jpg

Edited by nquantum

Share this post


Link to post
Share on other sites
nquantum   
Quote

In case of demo/benchmarks I get error on 

'DWT_CYCCNT' undeclared (first use in this function)

'DWT_CTRL' undeclared (first use in this function)

I found info in CMSIS I will try replace: 

DWT_CYCCNT to DWT->CYCCNT

DWT_CTRL to DWT_CTRL

Then compile no error. I haven't bring ST board now. Will try test result tonight.

Share this post


Link to post
Share on other sites
nquantum   
Quote

Can you tell us what kind of performance you get out of the display? What's the maximum refresh speed you get with your driver/board file?

For benchmark tools I got 123,227,408 Pixels/s. It not a refresh rate. How can I measure refresh rate?

Or 123,227,408/(800x480) ?

Edited by nquantum

Share this post


Link to post
Share on other sites
nquantum   

I've finish let try these files. Thank for Maytham this is base from him. Thank for suggest of Joel Bodenmann and inmarket for detail information.

Driver depends on ST HAL , Component , BSP also I take auto-calibrate function from FT6x06 driver supply by ST.

 

Take a look and please comment/review.

Also still curious to know this. 

Quote
Quote

Can you tell us what kind of performance you get out of the display? What's the maximum refresh speed you get with your driver/board file?

For benchmark tools I got 123,227,408 Pixels/s. It not a refresh rate. How can I measure refresh rate?

Or 123,227,408/(800x480) ?

 

ft6x06.h

gmouse_lld_FT6x06.c

gmouse_lld_FT6x06_board.h

Share this post


Link to post
Share on other sites
nquantum   

Update driver files after I see: https://community.ugfx.io/topic/413-ft6x06-driver/

STM32F469 Discovery use FT6206.

The compatible of FT5x06 and FT6x06 I read from this topic let me check datasheet of both. There is difference FT5x06 can have touch point up to 10 but FT6x06 only 2. Also little bit difference in register. Some doesn't exist (according to datasheet) in FT6x06. So I update the define value.

 

However after test with demos/tools/touch_driver_test I found out that some of those don't exist register and compensate setting from FT5x06 do have positive effect. So I keep those compensate setting and give comment information in to file and also adjust some register.

Also found out that the precise touch of manual crosshair calibration effect whether I can touch near the edge of screen or not. According from drawing page. 

The more precise touch I do also proper GMOUSE_FT6x06_FINGER_CALIBRATE_ERROR and GMOUSE_FT6x06_PEN_CALIBRATE_ERROR value do effect the precise of touch result and near edge of screen touch. Drawing page let me verify those calibration. 

And I can see manual calibration does better job than auto calibration. The precision is better.

ft6x06.h

gmouse_lld_FT6x06.c

gmouse_lld_FT6x06_board.h

Share this post


Link to post
Share on other sites
inmarket   

Yes manual calibration will always give a better result than automatic calibration. The reason is that there is always some physical misalignment between the touch panel and the lcd screen. Automatic calibration calibrates values from edge to edge on the touch panel which is slightly different from edge to edge on the lcd screen (which is really what you want).

Manual calibration does calibration relative to the lcd panel which should always give a better result for the user.

Share this post


Link to post
Share on other sites
19 hours ago, nquantum said:

For benchmark tools I got 123,227,408 Pixels/s. It not a refresh rate. How can I measure refresh rate?

Or 123,227,408/(800x480) ?

µGFX doesn't use fixed refresh rates nor full-framebuffer updates. Therefore, you can't get a classic FPS (frames per second) value like on other video systems. The best thing you can do is clearing the display with two alternating colors using gdispClear() and measuring the time in between which gives you a pixels/seconds value similar to the benchmark that you were running earlier. However, you have to disable DMA2D as it would make the results become inaccurate. Also, in this case it's really hard to come up with a number that allows comparing the system to others because you have the LTDC which automatically refreshes the framebuffer. All you do when drawing something is writing to the framebuffer memory but nothing shows on the actual display yet.
I'm really more curious whether you have a "smooth" experience or whether it's laggy.

I know that the DSI / MIPI interface has two modes: Video mode and Adaptive command mode. When I remember correctly you're using Video mode which always streams the entire framebuffer content to the display. The adaptive command mode (again - when I remember correctly) would allow only updating partial display areas which is something that µGFX is very well capable of and which could vastly increase performance.
But I'm really unsure - I'd have to dive into the datasheet(s) again. You probably know more about that than me.

Share this post


Link to post
Share on other sites
nquantum   
Quote

µGFX doesn't use fixed refresh rates nor full-framebuffer updates. Therefore, you can't get a classic FPS (frames per second) value like on other video systems. The best thing you can do is clearing the display with two alternating colors using gdispClear() and measuring the time in between which gives you a pixels/seconds value similar to the benchmark that you were running earlier. However, you have to disable DMA2D as it would make the results become inaccurate. Also, in this case it's really hard to come up with a number that allows comparing the system to others because you have the LTDC which automatically refreshes the framebuffer. All you do when drawing something is writing to the framebuffer memory but nothing shows on the actual display yet.
I'm really more curious whether you have a "smooth" experience or whether it's laggy.

Yes that correct I write to buffer and LTDC use its AHB and FIFO stuff trough FMC/QUADSPI interface to take care of update screen. Then LTDC automatic send to DSI HOST stream to panel trough serial bus.

But smooth or not so sure. I should lag for some I think since it trough 2process, LTDC and DSI HOST. Since I only experiment with still picture only. Never try animation yet. Normally microcontrollers they direct use their I/O to interface with TFT/LCD? They have no LTDC? I never experience other TFT before only basic character LCD in those 8bit micro. This is my first TFT panel with 32bit micro. (very happy already to start to see 1st picture in TFT myself :))

 

Quote

I know that the DSI / MIPI interface has two modes: Video mode and Adaptive command mode. When I remember correctly you're using Video mode which always streams the entire framebuffer content to the display. The adaptive command mode (again - when I remember correctly) would allow only updating partial display areas which is something that µGFX is very well capable of and which could vastly increase performance.
But I'm really unsure - I'd have to dive into the datasheet(s) again. You probably know more about that than me.

You quite correct. I also attach pictures for reference. For video mode LTDC generate sync signals to DSI HOST then DSI stream serial to panel. For command mode send command and data to update GRAM of panel then panel controller take care of update panel.

Qualcomm datasheet give info quite clear. (ST make me so headache)

 

The DSI is a specification by the MIPI and is targeted at reducing the cost of the display
subsystem in mobile and embedded-computing devices. It defines a serial bus and
communication protocol between the host and the device (client). The bus includes one
high-speed clock lane and one or more data lanes. Each lane is carried on tow wires and uses low
voltage, differential signaling.

 

So I think that why they do care on price than performance. By reduce pin count can reduce complex of system also cost. I think it just like parallel port change to serial port that it. And for command mode they do need panel to manage more thing: GRAM, controller. Instead video mode so that it can use dumb display only to display streaming.

 

1.png

2.png

3.png

4.png

5.png

6.png

7.png

8.png

Share this post


Link to post
Share on other sites
inmarket   

The current STM32F469i-Discovery board files have been added to repository. Note it is not a complete (or tested) board file definition yet. I have just added it to the repo so that it doesn't get lost over time.

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×