2009-09-28 02:35 PM
TFT performance with STM32
2011-05-17 04:24 AM
Oh also, if I go with the Epson (S1D13517), it's a 16-bit AD-MUX interface. There's not much (if any) AD-MUX NOR flash out there running at 3.3V, so it would be a non-mux interface. Are there any significant overhead concerns as the DMA controller switches the FSMC between these timings/interfaces? Bear with these newbie sorta questions....
2011-05-17 04:24 AM
I can't answer much, but I have used both a 2.4'' LCD via SPI (as per the STM3210 eval board) and a 4.3'' 480x272 24bit colour driven by a custom framebuffer (Altera EPLD + SRAM on FSMC).
The SPI based LCD's are slow, simply due to the performance of the SPI interface. Unacceptably so I would say. The framebuffer version is much much faster, and even with my lousy framebuffer design it's perfectly acceptable. Chris.2011-05-17 04:24 AM
I'm hoping to squeeze quite a bit out of the STM32, and am asking some advice to those who have interfaced with colour LCDs. No specifics yet, just trying to get a feel...
1. I plan to use the DMA controller for several peripherals (ADC, SPI, UARTS) as well as for transferring graphics from external NOR flash to the LCD controller (Epson S1D13517) using the FSMC. It's a 4.3'' 480x272, 24bpp screen, so I'm worried that the display will end up sluggish as the higher priority tasks take over. The GUI would mostly consist of updating gauges/bar graphs (10-20Hz) and some basic menu/settings pages. I've heard that the LCD demo that comes with the EVAL board shows that the performance is not very zippy, but I've also heard that this may be due to the slow LCD controller. Thoughts? 2. Although I've got a proposed set of DMA channels to use for the various peripherals and there's no channel conflicts as mapped so far, I'm worried still that the DMA controller will get clogged by the transfer from NOR flash to LCD controller, resulting in performance problems with the other high priority tasks (UART, ADC, SPI, etc). Should I be concerned? 3. To ensure good performance, I'm considering an LCD controller with a more enhanced graphics engine, something with BitBLT and such, so that at start up, I can load all the graphics/fonts to graphic memory, then send simple commands to copy/paste graphics from within the non-displayed area of graphic SDRAM to the displayed SDRAM. Eyeballing the Fujitsu Lime, but the datasheet is very poor and riddled with errors, and I've not been getting great support to clarify things. Anyone try this part out? Is this getting a bit excessive, as maybe the STM32 with an EPSON and NOR Flash could do the trick just fine?2011-05-17 04:24 AM
I would recommend something like the Solomon Systech SSD1963 for a panel that size.
Also implements a 8080 interface that works well on the stm32 fsmc. Cheers sjo2011-05-17 04:24 AM
Sadly the Solomon Systech parts weren't quite available when I needed them. (datasheets but no actual parts). However, I would use one if I had to revisit the design.
Chris.2011-05-17 04:24 AM
@sjo-
Thank you - appreciated. Do post if/when you seek to commercialize. BTW - suspect many would appreciate several basic ''benchmark comparisons'' between STM32 and PIC32. (i.e. clear screen, draw filled rectangle, bit-blt, analog-in2011-05-17 04:24 AM
@sjo-
Months past I recall you mentioning the planned development of an SSD1963 based board for TFTs. Visited your site - can find no mention. Would you be so good as to provide an update on progress? Thanks2011-05-17 04:24 AM
we have completed two design's (STM32 and PIC32) using the SSD1963 and have a few customers using it.
We have not created any boards for sale yet, but his may change when we finish other projects. Cheers sjo