Lpc2000

--- In lpc2000@yahoogroups.com, "rodboyce70" <rodboyce70@y...> wrote:
> <snip>
> 
> There are 50 frames a second transmitted but each frame is an
> interlace.  So video output is even number scan lines in the frame
> then odd numbered scan lines.  A video scan line is 62.5uS including
> the sync-pluse.  I think that from memory the total sync pulse width
> in 12.5uS this leave 50uS of screen data.  So by dividing this 50uS
> into as many sections is you like you get a pixel width.  There are

AFAIR this is correct.

Pixel width is the main factor in a project like this.

For the sake of argument, lets say the display is 50 pixels across.
That means every one uSec a transition may accure. Using an interrupt
set to one uSec would make the cpu very busy. No time left to do much
of anything. Software loop means nothing else will ever be done. Even
at 60 Mhz what would be the overhead ?

So unless you want a seperate LPC cpu to control just the video
(overkill as stated in another post) just use a seperate controller (
pick your favrite design).

This is a great academic question, but has little practical value.

donhamilton


> 625 lines in a frame and I think 100 or so of them are take up with
> vertial refresh this leaves 525 for display.  So a counter that

PS: Your software can not stop, ever !!