Support for STM32F469i-Discovery

[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.

Edited February 5, 2017 by nquantum

[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.

[inmarket]

Yes that touch display looks fine.

[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 February 5, 2017 by nquantum

[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

[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

[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.

[Joel Bodenmann]

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.

[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.

 

[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.

[Guest joeyl]

What needs to be done to get uGFX working/complete on STM32F469 Discovery board. I just got one of these board and would like to help if I knew how.

[Joel Bodenmann]

The µGFX library v2.8 includes support for the STM32F469i-Discovery board that works out of the box. Please try that.

[cpu20]

An example project is now available in the downloads section!

 

 

Edited January 18, 2018 by cpu20

[Joel Bodenmann]

Cool, great work!  

[nquantum]

I'm improving old board files I've done before.  Before it depend on BSD driver and font from ST example project.  Since that is too much and not necessary for normally.  I changed it to use with code from CubeMX and dependence free from BSD driver and fonts.

 

I would like to ask.

1.

I've check LTDC driver in ugfx is Point and Block Model correct? And the require is : gdisp_lld_init() , gdisp_lld_draw_pixel()

It seem define in  gdisp_lld_config.h  which will use:

   GDISP_HARDWARE_DRAWPIXEL  for  gdisp_lld_draw_pixel()

   GDISP_HARDWARE_FILLS  for  gdisp_lld_fill_area()        

   GDISP_HARDWARE_BITFILLS  for  gdisp_lld_blit_area()

 

From what I understand is DMA2D is use in  gdisp_lld_fill_area()  and  gdisp_lld_blit_area()  but  not in gdisp_lld_draw_pixel()  am I correct?

It seem that if I comment out DMA2D not use them only gdisp_lld_draw_pixel() is working already. But I'm not sure there is some where in call use DMA2D when gdisp_lld_draw_pixel()  is called or not? I ask because I will change some code that use DMA2D setting come from CubeMX for easy understand and adjust. So when use next project all setting LTDC, DSI, DMA2D, FMC, RCC and Clock will generate from CubeMX and only board file/driver then link with those. Is gdisp_lld_draw_pixel() involved in convert color pixel that use benefit of DMA2D or not?

 

2. 

It seem like old of my board file and the current one that upload to repository is use Adapt command mode. There is also Video mode to choose. Which is should better in term of smooth transition picture. But I'm not have much experience on this. It seem like Adapt command mode use frame buffer to refresh display.

If use Video mode should be better? I think you have more experience can you please explain use case or benefit of this two mode? Command mode vs Video mode.

 

Thank

Edited February 2, 2018 by nquantum

[inmarket]

1. gdisp_draw_pixel does not use DMA2D because it is much slower than simply getting the CPU to do it. DMA reduces CPU cycles for larger transfers but the overheads of the setup are larger than the performance gains when you are setting a single pixel.

2. Unfortunately I don't know the answer to this. Reading the spec sheets should answer the question.

[kemenes]

Hy

Are there any updates on the official support?
(Also a beta public release would be nice )

[Joel Bodenmann]

The STM32F469i-Discovery board files have been added a long time ago.