|
Howdy all, I'm a final year engineering student (and a DSP virgin, only having worked with microcontrollers before) in Western Australia, and am working on a project which will involve driving a 800x600 TFT LCD with video generated in a C6711 DSK. I'm interested in your various opinions on the feasibility and possible configurations to achieve this, or whether there would be little time for the DSP to do much else, especially seeing as one option involves using the EMIF for the data lines... There are 20 signals which must be generated to drive the LCD: 18 pixel colour lines (6 bits each for RGB), a pixel clock which latches the colour information in for each pixel, and an enable signal which indicates when valid data is available for each horizontal line. The video must be shown at 25fps, and from this I have calculated that the LCD's pixel clock must be driven at a minimum of 12.75Mhz, allowing for vertical blanking and so on. If the minimum pixelClock frequency is used, on about ~94% of negative pixel clock transitions there will need to be colour data available to be latched into the LCD. It is my hope that the following arrangement (or a variation) could be used: -Pixel Clock: generated by dividing an existing clock signal from the C6711 - either the CPU or memory clock. -Enable signal: Generated using one of the two timers. -Data Signals (18 bits): Hopefully these can be connected to the EMIF, (perhaps with a latch in between the DSP and the LCD) such that DMA can be used to reduce load on the DSP for the transferring operations. Given the extremely regular and frequent signalling needed for the pixel colour data (every 78ns, max) would the EMIF end up unable to talk to the SDRAM as needed (and therefore result in crippling of the DSP's calculating abilities)? Could I use 18 pins from somewhere else (eg HPI) to handle the data bus for the LCD, so that there is less impact on the EMIF? As I indicated before, I've not used the C671x DSP, or any other, previously, so any feedback would be appreciated. Thanks, Josh Lowe |
|
|
Suggestions: Driving an 800x600 TFT from C6711
Started by ●March 18, 2004
Reply by ●March 19, 20042004-03-19
|
Hello Josh,
Assuming that your calculations are correct...
1. I believe that you can generate 12.5 Mhz with the timer
2. HPI is an INPUT to the 6711. You will have to use the EMIF.
3. You cannot hardly deal with a pixel deadline [78ns]. The classical
way is to buffer up some or preferably all of the row. this would loosen
up your timing to providing 800 pixels about every 60usec. Of course this
will require a fifo [preferably implemented in programmable logic].
If you try to drive the pixels directly from the EMIF with EDMA, you could
still get a few mips out of the DSP, but you would HAVE TO HIT YOUR 78ns
DEADLINES!!
mikedunn
joshtlowe <j...@hotmail.com> wrote: Howdy all, |
Reply by ●March 22, 20042004-03-22
|
Josh- > I'm a final year engineering student (and a DSP virgin, only having > worked with microcontrollers before) in Western Australia, and am > working on a project which will involve driving a 800x600 TFT LCD > with video generated in a C6711 DSK. I'm interested in your various > opinions on the feasibility and possible configurations to achieve > this, or whether there would be little time for the DSP to do much > else, especially seeing as one option involves using the EMIF for the > data lines... I would suggest using the DSK C6711 board + IDK daughtercard. You can get the logic source for the XCV100 video interface from TI, and then modify that to support your LCD interface in addition to the standard S-video and PC video output that TI provides. You can define additional logic I/O pins to drive the LCD interface and go from there. U will likely need to solder wires to pins on the FPGA (u can get most of these get from daughtercard connector pads) and to the TPV3026 video output device. But this is an academic project, so what the heck. Your Prof will be very impressed anyway when he sees those blue wires :-) The advantages are obvious: start with working algorithms such as MPEG2 and working logic source, including signals already defined and debugged such as pixel clock. Most importantly, the daughtercard already has additional dual-port video buffer SDRAM (being filled by DMA writes from DSP memory), and the logic already has video line buffer output that you *really* need in order to run in real-time and meet the pixel deadlines that Mike and others have mentioned. If it were me, I would modify the logic in such a way that the PC video continues to display, to maintain a 'gold standard' for comparison at all times as you mess with the logic and DSP code. -Jeff > There are 20 signals which must be generated to drive the LCD: 18 > pixel colour lines (6 bits each for RGB), a pixel clock which latches > the colour information in for each pixel, and an enable signal which > indicates when valid data is available for each horizontal line. > > The video must be shown at 25fps, and from this I have calculated > that the LCD's pixel clock must be driven at a minimum of 12.75Mhz, > allowing for vertical blanking and so on. If the minimum pixelClock > frequency is used, on about ~94% of negative pixel clock transitions > there will need to be colour data available to be latched into the > LCD. > > It is my hope that the following arrangement (or a variation) could > be used: > > -Pixel Clock: generated by dividing an existing clock signal from the > C6711 - either the CPU or memory clock. > > -Enable signal: Generated using one of the two timers. > > -Data Signals (18 bits): Hopefully these can be connected to the > EMIF, (perhaps with a latch in between the DSP and the LCD) such that > DMA can be used to reduce load on the DSP for the transferring > operations. Given the extremely regular and frequent signalling > needed for the pixel colour data (every 78ns, max) would the EMIF end > up unable to talk to the SDRAM as needed (and therefore result in > crippling of the DSP's calculating abilities)? Could I use 18 pins > from somewhere else (eg HPI) to handle the data bus for the LCD, so > that there is less impact on the EMIF? > > As I indicated before, I've not used the C671x DSP, or any other, > previously, so any feedback would be appreciated. > > Thanks, > Josh Lowe > > _____________________________________ > Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. > > _____________________________________ > About this discussion group: > > To Join: Send an email to > > To Post: Send an email to > > To Leave: Send an email to > > Archives: http://www.yahoogroups.com/group/c6x > > Other Groups: http://www.dsprelated.com > > Yahoo! Groups Links > > |
