3
\$\begingroup\$

I am designing a system where a DSP (like the TMS320VC5501) processes some video data and outputs it to a PSP screen (the ones sold on sparkfun). The issue I'm having here is designing the video output interface. I'm thinking that I should have a video buffer and maybe a CPLD to read data and spit it out to the PSP screen, but the exact details haven't been completely worked out.

My main concern is timing. The DSP will be writing image data to the video buffer as fast as possible which might not leave enough room for data reads on the output side. I've looked around and it seems like GPUs these days use fast SDRAM which suggests that I should use it (since it's obviously working for them), but if I do then I'm blanking on how to read from it to output to the display. (The DSP has an SDRAM controller, but I don't want to load it with constant display requests. I want to use it's processing power for actual processing as opposed to memory games) Another alternative is VRAM, but this is a really old method and seems to be going out of style. Might be my best option though...

As another thought, I can use DMA to burst-write 11520 bits (480pix x 8bits x 3colors) to a shift register during hsync via an interrupt (hsync/vsync will be PLD controlled). From there, the PLD will control that shift register to output the data using the correct timing. I have to double check the numbers, but this seems like a plausible solution.

Anybody have any insight on this?

\$\endgroup\$
3
  • \$\begingroup\$ Normally if you want to draw a line on screen, or write some text on screen , it's better to handover that job to GPU rather than implementing bersenham algorithm in your CPU. For bitmaps , you could use DMA thing. \$\endgroup\$
    – Standard Sandun
    Commented Dec 25, 2012 at 2:41
  • \$\begingroup\$ Olin lanthrop is the right person who could answer this question. \$\endgroup\$
    – Standard Sandun
    Commented Dec 25, 2012 at 2:42
  • 1
    \$\begingroup\$ If you want to tackle it, get an FPGA board as a more flexible prototype solution, where you can build logic and have a (limited) amount of RAM which you can use in either one-port or two-port form. That should let you experiment with design ideas before investing a lot in building hardware optimized for a given path such as your line-burst idea. Of course if the requirement is off the shelf, the most cost effective solution likely is as well. \$\endgroup\$
    – Chris Stratton
    Commented Dec 25, 2012 at 3:42

1 Answer 1

Reset to default
3
\$\begingroup\$

Normally the video interface logic (video controller) will read from some sort of RAM and output the proper video signals required by the display. I highly recommend that you don't try to create your own video controller by interfacing some sort of RAM and CPLD to your DSP. Doing a video controller is hard. Really hard.

Don't take this the wrong way, but your question is proof that you don't yet have what it takes to make your own video controller. This is not really a bad thing. Few people have what it takes. A senior electrical engineer with 15+ years of experience would probably take 3 months to create, build, and test such a device while working 40 hours a week on it.

The "correct" way to solve this would be to choose an MCU or DSP that already has a video controller in it. For example, TI makes some nice ARM Cortex A8 based MCU's that are as fast or faster at signal processing as the TMS320VC5501 for not a lot of more money (compared to other methods of doing this). This method also does not require extra memory for video (it is stored in the normal DDR3 SDRAM as what the CPU uses).

Other solutions would require doing things like adding an MCU w/video to the PCB along with the TMS320VC5501. Or getting an FPGA+SDRAM to do the same function (and then designing that logic). Both of these solutions are crazy given that the TMS320VC5501 is not that fast of a DSP and you get a huge bang for the buck from the ARM Cortex A8's. Not only will these solutions cost more, but they also more complex, take up more PCB space and will not operate as well.

\$\endgroup\$
7
  • 4
    \$\begingroup\$ While perhaps not cost effective for use in an actual product, doing one's own video controller as a learning project has a LOT to recommend it. A basic one is just a little state machine, fully approachable by anyone with a concept of synchronous logic. Everyone with an interest should really do one sometime - even if only to gain more perspective on the features of SOC peripherals. \$\endgroup\$
    – Chris Stratton
    Commented Dec 25, 2012 at 3:30
  • \$\begingroup\$ @ChrisStratton I agree with you, 100%. But the OP needs to use a video controller first, or at least understand them better. Video controllers are not something that you can really do a reasonable job on without having experience with them first. \$\endgroup\$
    – user3624
    Commented Dec 25, 2012 at 3:36
  • 2
    \$\begingroup\$ Strongly disagree with that. The poster clearly indicates sufficient awareness of the requirements to tackle it as a learning project. There really is not much complexity to "count this many pixels, change mode, count that many pixels, change mode, etc" and outer-loop counterpart in the other axis; if you've played with xvidtune or looked at a monitor timing diagram or video signal on a scope, it's pretty obvious what you need to do. Complexity comes in when you want to do tightly interleaved memory access, and possibly with the analog requirements of LCD's (which can lead to ODD behavior) \$\endgroup\$
    – Chris Stratton
    Commented Dec 25, 2012 at 3:39
  • \$\begingroup\$ @ChrisStratton Yes, the complexity is not with spitting out the video data, but with the memory interface. I do have experience doing this, as I have done several PCB's with video outputs. \$\endgroup\$
    – user3624
    Commented Dec 25, 2012 at 5:09
  • \$\begingroup\$ @DavidKessner Just as a side note, I've made CRTC controllers and VRAM controllers before (in VHDL) so I have a pretty good idea of how all that works. I just want to make sure that my design ideas will possibly satisfy timing requirements between the components in a way that will improve throughput. Switching to a different MCU may be a good idea. I wanted to pick something that wasn't overly complex, but if this DSP is not suited for the task at hand, then I may as well... \$\endgroup\$
    – Koma
    Commented Dec 25, 2012 at 5:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.