SSD1289 frame buffer

Has anyone ever tried to use the SSD1289's internal RAM as a frame buffer so that the display could be updated instantly? Is it even possible? I looked through the datasheet (http://www.gpegint.com/files/library/files/supportpdf/Driver%20IC%20SSD1289.pdf) and it seems to be possible using some 18-bit mode, but I don't really understand it.

Bump. I'm getting back into this project soon and would still like to use the frame buffer.

If you are after fast, I'm developing a library that uses various techniques to draw quickly. Take a look, it'll be out hopefully within a couple of weeks.

I've got plenty of speed alright, I should have mentioned that I'm using a 32 bit MCU @ 168 MHz. What I want, however, is instant :). The idea is to play (low framerate) video and I figure it will look better if the data is sent into the displays RAM first, with the screen being updated once the RAM is filled, as opposed to updating each pixel at the speed the MCU can send data, making it slightly noticable that the screen is updating from one side to the other. So essentially I need to manually control the refresh/update rate of the screen or somehow stop it from displaying new data until I tell it to.

You seem to be asking for double-buffering, which it doesn't support. I wondered if you can switch from RGB interface
(ie video) to GRAM and back, but the datasheet doesn't look promising, they are separate modes.

If you can drive in 16 bit or 18 bit parallel you can update the RAM upto 130 times a second in theory - at 100ns cycle time. 130 FPS
is faster than the LCD pixels can respond I believe.

Yeah, double buffering is what I want. So far the only way I've been able to do it is to stop the main oscillator (register 0x00) while loading the data, but that makes the screen fade out as it's not being updated. Also, it takes about 50ms for the oscillator to start back up and display all the new data for some reason, which is useless for video.

I don't quite have the speed to update at 130 fps unfortunately. Together with SDIO reading and LCD writing I get about 15 fps without using the DMA.

edit - typo

Can't you read SD to RAM and then blast that to the LCD using an assembler loop? Which MCU?

STM32F407VET is the MCU. One frame is 320x240x16/8 = 153600 bytes. the MCU only has 192KB of RAM if I remember correctly, which doesn't leave much room for other non-LCD related stuff. I'm thinking about adding external RAM but I'm not sure how fast that will be.

Also how would I go about doing IO in assembler? For example, let's say I want to put 0x00 on port E. AVR seems to have a convenient OUT instruction which ARM cortex M4 doesn't. Couldn't I just MOV 0x00 into the output data register of port E? the output data register of port E on my MCU is 0x40021014 but I have no idea where to go from there.

EDIT: ok I figured it out. Turns out all my values have to be in registers and I actually use LDR and STR. I don't understand why I can't replace R3 in the STR line with 0x0. Code for future reference:

asm("ldr R1, =0x40021000");//pointer to GPIOE base
asm("ldr R3, =0x00000000");//to set all bits low
asm("str R3, [R1, #0x14]");//store R3(0x00) into R1(GPIOE_base) + 0x14(ODR)

I don't think it will be much faster than doing it in C though.

i think so, You seem to be asking for double-buffering, which it doesn't support,thanks for your sharing.

I don't understand why I can't replace R3 in the STR line with 0x0.

Because that is not how ARM assembler instructions work. The processor is not designed to do that.
All store instructions involve storing the value of a register not an immediate value.