Using WAITVID to drive 8-bit LCD graphics display?
Mark_T
Posts: 1,981
I'm wondering if I'm the first to do this, searching hasn't turned up anything obvious.
The LCD I have is 320x240 TFT module from TechToys with ILI9320 driver chip. The ILI9320 can provide SPI, 8, 9, 16 or 18 bit interfaces but this board just gives the 8-bit interface to you. The colour is 5:6:5 bit RGB so 2 bytes are needed per pixel.
Having found initialization code from their resources in C I managed to get it basically working, but wondered if I could speed it up via WAITVID - this can provide the 8-bit data but the nWR strobe has to be generated too. So I used CTRB to run at the same frequency as CTRA (PLL divide by 16 so waitvid clock is same as counter). Before going into video mode I set the nWR high, set counter B to use it as the output pin (NCO single ended - I park it on an unused pin at other times to avoid losing relative phase). Then as the video hardware is enabled I set nWR low so the counter's output can OR into it and provide the (negative going) pulses.
To synchronize afterwards a redundant waitvid is used, then the nWR pin is forced high to stop counter B pulsing it, and eventually counter B is steered to a redundant pin so nWR can be programatically controlled in other parts of the cog.
Seems to work now, 10MHz clock to push bytes into the LCD's graphics memory, but only in multiples of 16 or 32.
I have some questions: Is it safe to alter VSCL on the fly to change the number of bytes shifted out on the last waitvid? If so when? I'd like to be able to send a arbitrary even number of bytes with the video-generator
If you do a waitvid and then shutdown the video generator by setting the mode bits to 00 in VCFG, does that immediately reset the video pipeline so it can be used again without delay?
If anyone else has a ILI9320 based LCD then I've attached preliminary code, and here's videos: http://www.youtube.com/watch?v=G6pt6NFvAwU
http://www.youtube.com/watch?v=ObA5nL3uCBY
[edit: Note there is now much better code in the Obex, see post #7]
The LCD I have is 320x240 TFT module from TechToys with ILI9320 driver chip. The ILI9320 can provide SPI, 8, 9, 16 or 18 bit interfaces but this board just gives the 8-bit interface to you. The colour is 5:6:5 bit RGB so 2 bytes are needed per pixel.
Having found initialization code from their resources in C I managed to get it basically working, but wondered if I could speed it up via WAITVID - this can provide the 8-bit data but the nWR strobe has to be generated too. So I used CTRB to run at the same frequency as CTRA (PLL divide by 16 so waitvid clock is same as counter). Before going into video mode I set the nWR high, set counter B to use it as the output pin (NCO single ended - I park it on an unused pin at other times to avoid losing relative phase). Then as the video hardware is enabled I set nWR low so the counter's output can OR into it and provide the (negative going) pulses.
To synchronize afterwards a redundant waitvid is used, then the nWR pin is forced high to stop counter B pulsing it, and eventually counter B is steered to a redundant pin so nWR can be programatically controlled in other parts of the cog.
Seems to work now, 10MHz clock to push bytes into the LCD's graphics memory, but only in multiples of 16 or 32.
I have some questions: Is it safe to alter VSCL on the fly to change the number of bytes shifted out on the last waitvid? If so when? I'd like to be able to send a arbitrary even number of bytes with the video-generator
If you do a waitvid and then shutdown the video generator by setting the mode bits to 00 in VCFG, does that immediately reset the video pipeline so it can be used again without delay?
If anyone else has a ILI9320 based LCD then I've attached preliminary code, and here's videos: http://www.youtube.com/watch?v=G6pt6NFvAwU
http://www.youtube.com/watch?v=ObA5nL3uCBY
[edit: Note there is now much better code in the Obex, see post #7]
Comments
It resets everything except the internal frame counter. Which means when you're halfway through a waitvid say 50 out of 100 frame clocks then stop the h/w you'll still have to wait 50 frame clocks before vscl is re-fetched (once the h/w is re-enabled). I haven't looked at what is actually shifted out at this point but it's most likely not what you want.
AFAIK, the counter flip-flops (A1 and A2) and the frame counter are the only things not being resetA which will cause trouble when you rely on it.
A this includes hard-reset, cogstop, disabling counter(s) and/or video h/w
Did you figure out how to do it for non-multiples of 16 or 32?
Yes, just now managed to - set low bits of VSCL after the last full waitvid with MOVS to the right number, then the next waitvid will do the reduced number of transfers, then a final dummy waitvid to synchronise the suppression of counter B pulses.Goes at 10MB/s, each 16 bit pixel takes 200ns to transfer (whole screen clear in 15.5ms)
Am working on a more configurable driver with line/rectangle/text drawing.
I can do it now, but it's noticeably slower than on a real TV...
Not sure there's a clear path to doing this with waitvid, but maybe there is...