SSD1963 and STM324 FSMC

[linas2]

Posted on March 01, 2012 at 14:49

Hello,

i have working code for SMT32F103 without fsmc controller, and now i was able to make code for STM32F4 with fsmc controller but it look like speed is the same. Where fsmc will give my speed improvement ? or i made something wrong ?

[Tesla DeLorean]

Posted on March 01, 2012 at 15:37

Perhaps you should provide some more detail on your alternate method, so there'd be some basis to compare-and-contrast implementations. And details of what parameters you're testing and how.

The FSMC provides direct memory space access to external devices, improved cycle times, and DMA transfer capabilities.

[linas2]

Posted on March 01, 2012 at 16:10

http://www.mediafire.com/?b4x6p1y23p84eyo

inside is full project (Atollic TrueStudio) Pin functions is in lcd.c, reset is high with pullup resistor, do it manually, or make small code for it. I don't know to much about programing ( all inicialization stuff, all i did i taked STM32F103 fsmc driver, updated FSMC and Control lines function, and that do the trick If some on can improve it, please do it and share with others, thank you

http://www.youtube.com/watch?v=s89z_iHwXh4

[Tesla DeLorean]

Posted on March 01, 2012 at 17:26

I don't know a whole lot about the SSD1963 part, but it strikes me that if the driver keeps track a little more about what registers are programmed with what values are currently set, and tries to optimize/cache run lengths you'll get a lot better speed.

For example, writing characters a pixel at a time setting the X, Y, colour every time seems very inefficient. Doesn't it support sending a raster? or multiple rasters? That's then compounded when you try to write a string of characters. If you can paint a bitmap to a specific X Y location, presumably you could DMA that and offload the work from the CPU.

[linas2]

Posted on March 01, 2012 at 18:02

ok, just tested side to side, and it looks like it's 2x faster than old driver with cortex m3.

Only optimization i use is by knowing what pixels should be changed, and just fraction of data should be done to make the job. here is good example of my last project: without any optimization, just paint code from ram (no fsmc), and you can clearly see flicker.

http://www.youtube.com/watch?v=Hz7NbZL5DcM

and now full program with lot's of calculation and massive manipulation to obtain best speed and good user experience (tons of optimization, just right pixel are updated, rest is stationary)

http://www.youtube.com/watch?v=tknYPA5YFDQ

[linas2]

Posted on March 02, 2012 at 06:08

My friend point out that in system_stm32f4xx.c file PLL_M should be changed from 25 to 8 (since i have that crystal on my discovery board) and that boost 4x again,

and same should be done in stm32f4xx.h, but that won't help alot. Maybe where is more clock setup for making this faster ? ( or best would be buy 25MHZ crystal and solder to board, so default setting will be used ? )

[Tesla DeLorean]

Posted on March 02, 2012 at 13:47

No, you just change the software to reflect the actual hardware you are using. The F4 is capable of running at 168 MHz using a 8 MHz external oscillator. If USB is not important the 16 MHz internal oscillator should suffice.

Make sure HSE_VALUE, and the PLL settings are suitably defined.

[linas2]

Posted on March 02, 2012 at 15:15

i made video to compare STM32F407 with STM32F103 rendering same code

Note, is that  lcd_set_pixel_color function was used , and it's alot slower than lcd_clear function.

http://www.youtube.com/watch?v=NCEumRJvUx8

[alberto239955_stm1_stmicro_com]

Posted on March 26, 2013 at 18:25

[alberto239955_stm1_stmicro_com]

Posted on March 26, 2013 at 18:27

Sorry for including my message as part of the original, quoted, message.

Please click on ''Show quoted message'' to see it.