Support for STM32F469i-Discovery

[inakto]

Hello, wondering when there will be support for the new discovery board. Thanks

[Joel Bodenmann]

Hello and welcome to the community!

We recently received such a development board and we are looking forward writing board files and example projects for that board. However, with our current schedule that might a couple weeks until we get to it.

If you are interested we can strongly recommend you doing that yourself. As the board uses the LTDC of the STM32F4 you can use the existing STM32LTDC driver which is known to work well with various STM32F4 and STM32F7 targets. If done right all you have to do is implementing the corresponding board file. You can find the board file template under /drivers/gdisp/STM32LTDC/board_STM32LTDC_template.h. If you have questions we are of course happy to help wherever we can.

 

[inakto]

Thanks for your quick reply. I will give it a shot and report back.

[inakto]

Hello, A friend of mine helped me get it working on the F469i, any idea when official support will be coming?

[Joel Bodenmann]

Good to hear back from you!

There's currently really no deadline for that. If required, we can ensure that it will be there for the µGFX 2.7 release that should take place in mid-September.
However, it sounds like you have working board files. Is everything working including the touchscreen using the STM32 Cube HAL?

[inakto]

Yes it is working using cube. Touchscreen works. He tells me it's a bit of a hack but I can post the project if it will help expidite an official release.

[Joel Bodenmann]

Yes, if you can post your work that would definitely help us speeding up the process!

[inakto]

I PM the project to you. My friend is wondering where he can find the studio project file for your demo projects, if it was made in studio.

[Joel Bodenmann]

Thank you very much for sending the project. Also big thanks from us towards you friend!
We will try to get it done this week.

I'm afraid that demo wasn't created with the µGFX-Studio. This might be interesting to you: 

 

[inakto]

Joel, that looks very nice indeed. I look forward to using the new tool since we are building a rather complex GUI with a lots of screens for adjusting settings and displaying diagnostic information.

I will also attemp to implement slippery map tile window in uGFX, similar to this. https://www.opencyclemap.org/

 

[Joel Bodenmann]

1 minute ago, inakto said:

Joel, that looks very nice indeed. I look forward to using the new tool since we are building a rather complex GUI with a lots of screens for adjusting settings and displaying diagnostic information.

It will take quite some time to get it to a usable state. But we are working on it as we speak

 

2 minutes ago, inakto said:

I will also attemp to implement slippery map tile window in uGFX, similar to this. https://www.opencyclemap.org/

Wow, that sounds like quite a project!
Please keep us up too date about your progress. We are very interested to hear more about it!

[olegator]

Wow! Really time is big spiral 

10 years ago, i've created the map software with tile engine for popular in that times Symbian phones - http://my-symbian.com/forum/viewtopic.php?t=22983&postdays=0&postorder=asc&start=0

There was CPU arm9 with 150-200Mhz clock freq, and it was enough for smooth decoding png/jpg tiles, then rendering them in real time and smooth scrolling. Therefore, your project have good chances too success - STM32F469i has a better performance and more RAM, than that old smartphones.

So, if you have any questions about tile map engine - you are welcome to ask it here, i'll try to help 

 

 

[Maytham]

Hi,

I see inakto has somewhat of a working STM32F469 board with uGFX. Any news on when the official support for the board will be available? I am pretty much a noob and don't really know what I am doing to get things working without official support!!!!

Thank you,

[Joel Bodenmann]

Hello Maytham and welcome to the community!

@inakto sent us his project which is working. However, it is far from a state where we could just copy-paste and include it into the repository. We started working on this and we got the basic display stuff working. We didn't look into the touchscreen stuff yet but that should be rather straight forward because µGFX already has a driver for that touch controller.
The main issue is that the official STM32F469i-Discovery demo(s) from ST themselves use the DSI in a the video mode. That is by far the "worst" mode to use. From what we can tell you would only use that mode if you're short on memory which isn't the case on that board.
Theoretically we can just take the ST board files and wrap them around the uGFX board files, but the DSI definitely wouldn't be working at its maximum performance.

[inakto]

On 8/26/2016 at 20:01, olegator said:

Wow! Really time is big spiral 

10 years ago, i've created the map software with tile engine for popular in that times Symbian phones - http://my-symbian.com/forum/viewtopic.php?t=22983&postdays=0&postorder=asc&start=0

There was CPU arm9 with 150-200Mhz clock freq, and it was enough for smooth decoding png/jpg tiles, then rendering them in real time and smooth scrolling. Therefore, your project have good chances too success - STM32F469i has a better performance and more RAM, than that old smartphones.

So, if you have any questions about tile map engine - you are welcome to ask it here, i'll try to help 

 

 

Thanks for your offer, I'm glad you think the project is feasible. I was most worried about the decoding of the PNG files, as the map tiles come in that format.

@Joel Bodenmann I tried loading BMP files but it is rather slow (10 fps?). Also, I tired enabling pixmaps to boost performance but there are multiple errors when the #define is enabled.

For the map area I am using a window object and using the primitive draw methods to draw to only that window. This seems to work well enough.

Keep up the good work, I'm glad support is coming soon.

 

 

[inmarket]

With regard to image display speed there can be several factors at play...

1. uGFX does not decode the image to memory normally. That means that each time you display the image it re-reads it from the source storage and redecodes the image. The solution is to use the gdidpImageCache() function if you have sufficient ram.

2. Where you store the image is important for the speed of the read/decode. For example, reading from a sdcard is going to be much slower than reading from ROMFS.

3. Pushing pixels to the display can be a slow process on some hardware. For example an i2c based controller is going to be much slower than a framebuffer controller in shared ram. Even then things like the ram bus bandwidth can be a factor eg a 800x600 display being refreshed at video rates will use a significant portion of a normal ram available bandwidth.

If you are looking at fast refreshing of a portion of the display also have a look at the gdisp streaming calls. They provide the lowest latency method of sending data to the display in viseo style applications. See the gdisp/streaming demo.

 

[inmarket]

With pixmaps there is a known incompatibility with the single file make method. To use pixmaps you need to be using the full makefile.

[inakto]

@inmarket Thanks for those points.

 I was using ROMFS to read the file from internal flash. I saw the caching, but when I tried to use it it returned error, not enough ram. I read somewhere else here that the library is not using external ram for caching, but there is a workaround. I also read someone say that the performance difference between cached image and flash image is negligible. Eventually we will he reading map tiles from sdcard so it will need to be cached once loaded.

I'll look into building the project with full make.

Thanks for you help here, I will keep posting as I learn how to use this great library.

[Joel Bodenmann]

I guess there is not much left to say for me...

Rendering a BMP from flash should definitely be a very fast operation. As mentioned in my previous post, the ST example uses a weird mode for the DSI. That may or may not result in lower performance, I haven't studied the datasheet enough yet to give a certain answer to that question.

 

7 hours ago, inakto said:

Keep up the good work, I'm glad support is coming soon.

Unfortunately we are very busy the following two weeks, it might take up to three weeks until we get to finishing the implementation of the official board files for the STM32F469i-Discovery board  

 

4 hours ago, inakto said:

I'll look into building the project with full make.

Please don't hesitate to ask if you have any questions.
The limitation(s) imposed by the single-fine-inclusion mechanisms are documented here.

 

7 hours ago, inakto said:

I was most worried about the decoding of the PNG files, as the map tiles come in that format.

You can find more information about the performance & resource requirements of our PNG decoder here (mind the comments!):

 

[inakto]

Hi @Joel Bodenmann & @inmarket my friend helped me again to get pixmaps working on the project in Keil. I am able to run the pixmap demo code located here: https://wiki.ugfx.io/index.php/Pixmaps However, I now have a problem in that I can only create pixmaps of size ~100x50 maximum. I suspect a memory limitation. Without larger pixmaps I can't really see if there is an improvement in rendering.

Thanks.

[inakto]

Increasing the heap size  to 90000 has allowed me to get 200x100 pixmaps

[inakto]

Short video showing rendering the same 200x100 pixmap over and over in a grid pattern as fast as possible. Ideally I'd have 1 big pixmap and then blit it all at once, but I ran out of internal memory. Next step is to try and put the pixmap on external SDRAM and evaluate the performance. I have seen this post but It's worth a try 

 

20160830_194253.mp4

[Joel Bodenmann]

Thank you for sharing the video.

Personally I am pretty sure that what you are getting there is way below the performance that the STM32F469i can deliver. As mentioned previously the DSI setup of the ST demos don't seem to use the optimal settings. Blitting a pixmap on a system like that should not not be a visible operation, it should happen so fast that it appears to be instant.

I hope that we will have time to write the proper board files before we release µGFX 2.7 by the end of the month. We are sorry for the delay, there's currently just too much on the ToDo list.

[inakto]

6 hours ago, Joel Bodenmann said:

Blitting a pixmap on a system like that should not not be a visible operation, it should happen so fast that it appears to be instant.

My friend and I managed to move the heap onto the external SDRAM. It turns out there is a frame buffer on there as well, so we had to move the heap beside the framebuffer on the RAM. 

Now I was able to increase the heap size and create a pixmap of 800x480. Blitting the entire screen takes about 1.2 seconds.

This is good enough for our UI development so we will continue with that and migrate everything over to official support when it happens.

Thanks for the continued updates on that.

 

 

[Joel Bodenmann]

Using a pixmap that spans the entire display area is a very bad idea in this particular case because you have to use gdispGBlitArea() to copy the contents from the pixmap to the frame buffer. Although you have DMA2D that can take care of this to free CPU resources you still pay A LOT of resources for doing that. The LTDC of the STM32 that you are using is able to handle two layers (framebuffers) natively. Unlike with the pixmap solution you will never have to copy anything around. All you do is swapping a pointer somewhere in one of the LTDC configuration registers. That is a very fast operation. You can even blend the layers, not just hard-swap them.

To use this feature you will have to modify the STM32LTDC driver that can be found in /drivers/gdisp/STM32LTDC and your board file. In your board file you will find that the ltdcConfig struct only initializes one layer, it keeps the second layer uninitialized by using LTDC_UNUSED_LAYER_CONFIG.
The recommended way of adding support for multiple LTDC layers is by using the multiple displays support of uGFX. After all the two LTDC layers are nothing but two displays as they are complete, fully features framebuffers. All you do is telling the LTDC which of the two you want to show on the actual display. You can use the gdisp_lld_control() and gdisp_lld_query() driver API to retrieve the GDisplay* pointer(s) to the additional layer(s). This means that after calling gfxInit() in your code you simply use two gdispQuery() function calls to retrieve the two GDisplay* pointers that then allow you to draw to each frame buffer independently. You can then use a gdispControl() function call to swap the currently active layer.
As you can see you would proceed exactly the same as you would with your current pixmap solution: You draw to the pixmap using the GDisplay* pointer returned by gdispPixmapCreate() and you swap/copy the framebuffers using gdispGBlitArea(). With the new solution you would still proceed exactly the same, just that you use the hardware support of the LTDC to do all that which will really save you tons of resources.

I assume that this was quite a bit of dense information. Please feel free to open a new topic to further discuss this if you are interested in implementing this. We are happy to help wherever we can.
We definitely strongly recommend not using a full-size pixmap in your case, it's a waste of a lot of resources. Use the LTDC which has been designed to take care of this.