overcoming the 12 cycle GPIO waitstate for TFT LCD

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

overcoming the 12 cycle GPIO waitstate for TFT LCD

3,816 Views
s4w2099
Contributor II

Hello guys,

 

Is there any way to overcome the 12 cycle GPIO wait state in the coldfire MCF52255?

 

I am driving a 320x240 pixel TFT LCD with GPIO but I am getting slow frame rates because this bottleneck.

 

The LCD has a integrated controller that generates the VSYNC and HSYNC signals. All I have to do is put the pixel color on port TJ and port TI, then lower and rise a clock signal (just another pin in port UA).  

 

Any suggestions?

 

Message Edited by s4w2099 on 2010-02-13 06:08 PM
Labels (1)
0 Kudos
8 Replies

1,336 Views
scifi
Senior Contributor I

Doing LCD refresh with GPIO? This doesn't sound like a good idea. Shouldn't questions like that be asked at design stage?

If GPIO really is too slow for this, then you are out of options. You could have better luck with the Mini-FlexBus, but the MCF52255 doesn't have one...

 

0 Kudos

1,336 Views
s4w2099
Contributor II

Well IO waitstate thing does not seem to be listed in the manual or it is very well hidden. I was totally unaware of it. I was thinking of maybe switching over to to the 52259 144 pin package which does have  the mini flex bus.

 

This is my very first coldfire project and I am very satisfied with the CPU performance. Too bad that little detail is messing things up.

 

I will take a look at the flexbus and see if it actually would work. 

0 Kudos

1,336 Views
ianlovatt
Contributor III

The 52277 MPU has an LCD block which should work with a 320x240 TFT, might simplify the LCD part. However, we found designing for the external memory tricky as we were only used to working with Microcontrollers with onboard memory.

0 Kudos

1,336 Views
Nouchi
Senior Contributor II
But Mcf52277 has no ethernet controller, it could be a problem in some case...
0 Kudos

1,336 Views
s4w2099
Contributor II

Well, It might be a problem anyways because the LCD as I mentioned already has an integrated controller onboard that does all the HSYNC and VSYNC signals etc.

 

I am not using the FEC module right now so its OK if the chip does not have one. However I do need fast IO. I was looking at the flexbus and I believe it is the answer to my problems. For that All I have to do is go to the 52259 instead which is pretty much the same as the 52255. With the current setup I can only get 22 FPS.

 

Any other suggestions is appreciated.

 

0 Kudos

1,336 Views
TomE
Specialist II

MCF5329. It has an internal LCD controller, but you have to add external SDRAM and FLASH. A step up from the "just a simple microcontroller".

 

On that hardware I can update a complete QVGA screen in 3.6ms with a block memory copy. That's 277FPS.

 

Maybe you could get an LCD that accepts a serial data stream. The QSPI in the 5329 can send data at 20MHz.

 

Back of the envelope shows a frame rate of 16 FPS for (320 * 240 * 2 (bytes/pixel) * 9 (bits/byte) / 20MHz) if you're refreshing every pixel, which is worse than you're doing now. If you can just update the bits of the screen that change you should be able to get a faster frame rate.

 

The MCF52255 has an "external Mini-FlexBus" (whatever that is). That should be able to write data to the panel faster than the GPIO can.

 

0 Kudos

1,336 Views
s4w2099
Contributor II

Ok, thank you all for your replies.

 

I dont want to make the system too complex. This is just a hobby project so I have no pressure, just a toy. I have investigated the mini-flex bus and with the 52229 its doable. and it should be very fast.

 

If I fail with the 52259 I will attempt another MCU or Microprocessor that is more adequate for the job. This is my first experience with the coldfire family and I have fallen in love with them.

 

If you want to see what I am doing with the coldfire please take a look at:

 

http://www.xgamestation.com/phpbb/viewtopic.php?t=7359

 

Thank you

0 Kudos

1,336 Views
juanee
Contributor III

Are you using MQX to write to the ports or are you writing directly to the ports?  Can you show us a few lines of your code writing to the ports?

 

juanee

0 Kudos