I'm trying to do( what is effectively) animation using the LCD controller on the MCF5329.
The way to do this is:
- Have a Front (memory) Buffer and a Back Buffer, both the size of the frame,
- The LCD controller is displaying the Front Buffer,
- The next frame is composed/drawn/copied in/to the Back Buffer,
- At "the right time", The LCD_SSAR reg is loaded with the Back Buffer's address,
- Wait until the controller has taken/copied LCD_SSAR and is now displaying the new frame,
- Compose the next frame in the new back buffer (the old front buffer)
- Go back to Step 4.
The problem is getting the timing right.
Which requires use of the LCD controller interrupts.
There is nothing in the Reference Manual giving the timing or the operation, apart from register descriptions.
Testing shows the LCD_SSAR register isn't "live". If written during a frame the screen output doesn't change. The controller copies LCD_SSAR into some internal and invisible DMA controller SOMETIME before, during or after the vertical blanking time.
There are four interrupts available:
- Last word of data read for frame,
- Last word of data of frame sent to LCD panel,
- First word read for start of (next) frame,
- First word of data for frame sent to LCD panel.
As far as I can tell, the first three happen pretty much within the same microsecond, at the end of the frame and before the Vertical Sync and Blanking. The fourth one happens after the vertical blanking at the start of the frame.
Also note that the LCD controller has already decided on where the data for the next frame is and the end of the previous frame.
So how to flip frames and do it FAST enough for animation?
Initially we assumed that LCD_SSAR was "live" and had to be written between frames (after a vertical interrupt). That didn't work due to it being copied somewhere.
Are there any documents giving the real timing of the four interrupts, the video and the loading of LCD_SSAR? I've spend days on reverse engineering and I don't know enough to guarantee reliable programming (without flashes and frame overwrites) yet.
That's difficult enough. If I then want to animate the cursor or pan the frames back and forth I need the timing of the operations of the panning registers (like LCD_POR and how to change it and LCD_SSAR together).
reverse engineering this hardware
If I wait for the interrupt and reload LCD_SSAR between frames (just after interrupts 1, 2, 3) then the hardware doesn't use that value until after the NEXT interrupt and I can only get 30 frames/second and can only write to the back buffer half the time