dsPIC in VGA switching application

Hi,

(I'm more of a database guy, so if this is really stupid I apologize)

I have a situation where we need to run two monitors off of one video card but:

1- The card in place does not have two outputs
2- The card in place cannot be removed (or upgraded)
3- The monitor currently running has a touch sensitive screen and that functionality must not be impaired.

so.. I'm thinking that we can force the display adapter to 2048x768 mode and then split the signal between the two monitors. I think this is what Matrox's dualhead2go is doing, but that's expensive. This could be done with an oscillator but then the signal being recieved by the one monitor would be:

infoinfoinfoinfoinfo____________sync

and vice versa for the other. This may work, but I rather think the signal monitors would interpret null info as black and display the two images as half images. Worst case would have an electron gun hang at the side of the screen causing a fire or explosion.

So the tentative solution is to put something like a dsPIC33F downstream of the graphics card and before the monitors. the dsPIC would read the incoming R,G,and B signals, store them for one refresh cycle, and shunt them to the appropriate DAC (MCP4822 or similar I think) at the approriate speed for 1024x768 display. H-sync and V-sync would be amplified and sent to both monitors from the original signal, and the monitor id channel would only be open for the primary. This would cause a 1/75th second delay in monitor response but that shouldn't be noticible.

Q1. Is this on first glance feasible? the dsPIC would have to be reading and writing at the same time and there's not alot of unused time I think. At 75hz, each color wire changes voltage 786,432 times per frame or approx 59m times per second, while the PIC can only(!) handle 40MIPS.

Q2. I've found a fair bit on using ADCs but relatively little on DACs. VGA monitor signals have a wire for each color that caries a voltage from 0-.7v. I think the general is that I wire an output pin from the dsPIC to the MCP482x SPI and send the new voltage serially... Will the DAC stay at whatever I set it to until there's a new write action?

Thanks in advance for the help. This is driving me crazy. I want to go back to SQL.

A dsPIC's capabilities is completely out of the range of what is needed.
The processor is nowhere near fast enough. The ADC & PWM are nowhere near fast enough either, though there are some special, expensive codecs which can do this. Nor can the dsPIC buffer a frame. 1024x768x3 channels of 16 bits/channel is 2.4 megabytes!

You can get basic VGA out of a dsPIC (640x480) but even that consumes quite a bit of its resources.

Driving VGA signals is trivial for programmable logic (CPLDs and FPGAs). Even entry level CPLDs are capable of driving monitors with resolutions better than 1080P. I have a Spartan 3 board from www.digilent.us that I use as a video driver for a few of my projects. The board is identical to the one Xilinx sells as a starter package. In fact, Digilent makes it for them. It has built in SRAM and a VGA port which makes writing display routines fairly easy. If you want to add a highspeed DAC for more color options, there are plenty of I/O pins that are free to use.

Almost forgot. The board works with Xilinx's free webpack software so you can practice your VHDL or Verilog for free.

For $100, the board comes with a programmer which works with Impact (Xilinx's programming software) as well as a power supply. It is by far the best deal I have come across for FPGA boards.

Thanks for the replies.

So I guess I'm up the wrong tree in the right forest then. I'll take a look at the digilent board and see if I can't come up with something.

Have you considered using 8-bit 256 colour mode?

erm.. no not really. The pixel resolution controls the speed of the data stream. Using a reduced color mode would give me more discreteness(?) in the color information, but I'm going to read that 8-bit color at whatever resolution the ADC is capable of... a 12-bit or 16-bit ADC isn't going to read any faster because it's input was created by an 8-bit DAC right?

So I'd still run up against RAM and speed limitations in buffering the streams... unless you mean to read all three streams and store as an 8-bit color frame?

I don't see how it would be just as slow, an 8-bit colour mode would use half as much memory as 16-bit colour, and there'd be half as much data to shift too.

Hero999 said:

I don't see how it would be just as slow, an 8-bit colour mode would use half as much memory as 16-bit colour, and there'd be half as much data to shift too.

Click to expand...

The problem isn't the amount of data being moved on a clock-by-clock basis, it is the rate that you have send the data which is the problem.

Basic 640*480*60FPS requires a pixel clock of a little over 18MHz. Regardless of color depth, that means you have to process over 18 million discrete points every second (this doesn't include the front and back porch sections of the data that are not actually displayed). In addition you also have to generate your h_sync and v_sync signals which adds to the overhead. Even with clever addressing you still run into a bottleneck when you load your data and then shift it to the VGA port. Indirect addressing with auto increment can reduce this but you quickly run out of memory. This overhead is even worse if you have to access an external DAC.

The high speed repetitive looping nature of VGA signal driving is just too much work for microcontrollers because they are instruction based and can not run things in parallel unless there is dedicated hardware built into it. FPGAs on the other hand are very efficient at running repetitive loops at very high speeds. In addition, their architecture allows for parallel operation of whatever modules you develop in them. For instance, and FPGA can retrieve data from a dual channel RAM and immediately pass it along to a high speed DAC while at the same time it receives new data from a dsPIC through a serial link which is then transfered to the other channel of the RAM so it will be ready for use on the next scan pass of the monitor.

This is the reason why we have video cards in our computers. While modern processors are certainly fast enough to drive a monitor, it just consumes way to many resources. Instead the video card handles the mundane task of reading video buffer memory and generating the appropriate VGA timing and levels leaving the CPU free to work on more important things.

Why not just use one of these ?

https://www.vpi.us/vsplt-pc.html

2 ports(monitors) for $46, I would assume you just need to make sure both monitors are the same for driver purposes. This is assuming you want the same info displayed on both monitors.

i agree with phalanx. driving VGA signals with an FPGA is a piece of cake. i designed a 640x480 core with just two counters and a some comparators. i did it in verilog and if you have some experience of C, you can easily design a simillar core in verilog.

if you do plan to buy an FPGA development kit, i would suggest that you buy the Spartan 3E Starter Kit from Xilinx's online store. the S3E kit has more resources than the S3 kit, although at a higher price ($149 for the S3E and $99 for the S3 kit).

The problem with the various splitter is that they copy the same signal to two or more monitors. That's actually not that hard.. you have to amplify the signals but that's about it. The application here is to have the computer (video card) send two screens worth of information per frame and then split that information between two monitors.

An FPGA seems to be the way to go for sure. I just have never used one before-- I've played with the 8-bit PICs before which is where I got the idea for the dsPIC. I've now seen a picture of the board inside the Matrox product I mentioned in my first post, and it has an Altera chip at it's heart so I'm assuming that's how they solved the same problem. So, my next step is to read some tutorials on verilog, etc.

-TF
(When your project changes from a simple request for 10 minutes of hardware assistance to something where Step 2 is "Learn Verilog" you know the problem wasn't well defined to begin with