STM32F103VC + SSD1963 + EX. FLASH + FSMC

[Oshel]

Hello,

I am currently planning to set up a device that would use STM32F103VC uC and 800 x 480 TFT LCD with SSD1963 (8080). I would like also to add some external flash. The question is, maybe not directly related to uGFX, but is it possible to connect external flash AND the display to FSMC controller? Anyone have done something simillar? I am only asking if it is possible. As far as I know, there is a CS line so there shouldn't be a hardware conflict.

Another question is how it would affect the performance of uGFX? 
 

Thank you in advance.

[Joel Bodenmann]

Hi,

Using external FLASH and and LCD on the FSMC bus is possible - I have done it myself plenty of times.

The performance of µGFX itself will not be affected at all. You'll just introduce wait states on hardware level when the FSMC is busy accessing the external flash.
It's not that easy to tell how much the overall performance will be affected as this depends on a lot of stuff. However, this shouldn't be too much of a problem if you write your application to cope with this. After all, FLASH is usually not accessed all the time. You can use buffers and caching to minimize the amount of transactions to and from the FLASH.

I'm not sure how helpful this reply was, sorry.

[inmarket]

The stmf100 series chips are pretty low powered for such a large display. You will notice it in particular with larger images and full screen redraws. Fortunately you are using a graphics controller with its own framebuffer which will reduce bus bandwidth requirements.

As Joel said, it is possible to use the same bus for the flash, it just may slow certain operations. My thoughts are that it should be fine provided you are not trying to execute code from that flash or do large block fast DMA from there. In other words using it for resource storage (eg fonts and images) should be ok.

[Oshel]

Thank you for replies. I am aware that f103 can be too slow for this display. I am trying to build it "from the bottom"- I will try this uC and if it is not fast enough for my client then I will go to F4 or search for other solution with external ram instead of frame buffer inside controller. Currently I am waiting for a display delivery.

I was asking about the parallel flash because I assume it would be faster and more efficient than using SPI flash. But the price of the parallel flash is quite high so I gues I will leave this idea.

 

[Joel Bodenmann]

1 hour ago, Oshel said:

or search for other solution with external ram instead of frame buffer inside controller

That won't really help much. What you're doing in this case is directly writing into the framebuffer of the display controller. That is as fast as you can get. If you use external RAM yourself then you'll always have to copy it to the actual framebuffer or you have to use a display controller that's on your side (eg. integrated into the microcontroller) such as the LTDC which is featured by some of the F4 and F7 series. But that will not necessarily increase speed. It can be faster in certain cases but the performance gain is minimal and only applies in certain situations. The huge downside is that you get a lot more traffic on your FM(S)C bus because when using something like LTDC you connect the bare display panel to the microcontroller. The LTDC needs to take care of refreshing the display content which means that it needs to loop through the framebuffer in your external memory and send the correct pixel values to the display panel continuously - even if you're not changing the framebuffer contents.
Obviously there is a lot more to this than what I've just listed.

 

1 hour ago, Oshel said:

I was asking about the parallel flash because I assume it would be faster and more efficient than using SPI flash.

In general it will be faster, yes. But as you've discovered it's also often more expensive. Unless you have a lot of stuff to write (eg. when keeping log files and stuff like that) you won't get much more out of it. If you worry about performance then external RAM will be a huge improvement as it allows you to store decoded images and implement double-buffering and off-screen rendering.