Is the PIC fast enough to be useable as a character generator to overlay
text/graphics on NTSC video? About 10 chars/line is all I need; nothing
fancy. (I want to overlay date/time on a camera feed.)
You have about 63usec per line, maybe 60% useable is 38usec. On that
you need at least 60 pixels assuming the display is to spread across
the entire screen, so now you have 634nsec per pixel. Even at 20MHz
you are only getting 3 instructions per pixel, not enough to run a
pixel shift algorithm. However, maybe with a external parallel to
serial shift register or for that matter a relatively cheap VRAM....
Rgds, Brian.
______________________________ Reply Separator _________________________________
Subject: PIC and character generator
Author: "Paul Christenson [N3EOP]" <spam_OUTPJC130TakeThisOuTPSUVM.PSU.EDU> at Internet_Exchange
Date: 11/28/95 9:38 AM
Is the PIC fast enough to be useable as a character generator to overlay
text/graphics on NTSC video? About 10 chars/line is all I need; nothing
fancy. (I want to overlay date/time on a camera feed.)
On Tue, 28 Nov 1995, Paul Christenson [N3EOP] wrote:
> Is the PIC fast enough to be useable as a character generator to overlay
> text/graphics on NTSC video? About 10 chars/line is all I need; nothing
> fancy. (I want to overlay date/time on a camera feed.)
>
Outputting the text vertically rather than horizontally makes the timing
much easier - you get a minimum of the line scan time (64 us for PAL,
don't know about NTSC) to generate each line of each of your characters,
which should be trivial for any PIC. All you have to do then is clock out
the bit pattern at the correct rate; this can be done with a parallel to
serial shift register if you want to go really fast (i.e. narrow
characters).
> Is the PIC fast enough to be useable as a character generator to overlay
> text/graphics on NTSC video? About 10 chars/line is all I need; nothing
> fancy. (I want to overlay date/time on a camera feed.)
You can probably manage this. You'll need analog hardware for sync-detect
and DC-restoration. For the character generation itself doing date/time
shouldn't be a problem. The biggest issue is that the transmission of dots
to the screen must be done with an RC oscillator; if your PIC is driving the
pixels directly, then it would have an RC oscillator and not be very good
for timekeeping. I think my recommended approach would be to feed port A
and the lower 4 bits of port B into an 8-input mux and use the top 3 bits of
4-bit synchronous counter [driven by an RC oscillator] to select. The LSB
of the counter can be used to latch the output of the mux, and the MSB (in
addition to serving as bit 2 of the selector) would be sent to the PIC. Then
when port A is being output, port B can be updated; then when B is output, A
can be updated; etc.
BTW, a sync pulse should (in hardware) reset both the RC oscillator and
counter. The PIC can keep track of vertical timing.
> Is the PIC fast enough to be useable as a character generator to overlay
> text/graphics on NTSC video? About 10 chars/line is all I need; nothing
> fancy. (I want to overlay date/time on a camera feed.)
>
Offhand, I would say yes. Last summer, someone else mentioned using RRFs on
a port to shift new bits to a single pin that serves as the serial output. A
font with each character 5 pixels wide and blank pixels between characters
could be displayed with a sequence like:
movfw gline
movwf PORTB ;Display first pixel (B.0 is video output)
rrf PORTB,f ;display second from left
rrf PORTB,f ;
rrf PORTB,f
rrf PORTB,f ;display fifth active pixel.
clrf PORTB ;Video off.
nop ;Blank between characters.
Then repeat the sequence for each character that is to be displayed, using data
from a different RAM location:
movfw gline+1
etc. (repeat for 10 characters)
In order for this to work, pins B.1 thru B.4 have to be configured as
outputs so the bits will shift properly. The desired output is B.0, which
shold force the picture "white" while it is high, and have no effect while
low. If a black background is desired, that could be enabled while shifting
the pixels out using another output pin (of another port). The rest of port
B will output garbage during the display period but could be reused for user
interface at other times.
During the rest of the line, the characters stored in RAM would be converted
to pixels for the next line using a table. This process would probably take
about 10 instructions per character, so for a 10 character per line display,
the PIC instruction rate would need to be at least 100(overhead) + 80
(display) times the line rate, or a modest 2.8 MHz (11 MHz PIC clock). Of
course the final clock rate chosen has to be an integral multiple of the
line rate. At 2.8 MHz instruction rate, the line of characters would take
up 28 us, or about half of the visible part of the scan line.
This routine requires a byte of RAM to hold the pixels presently being
displayed for each character, in addition to a byte holding the character
code for the characters. This could push the limits of a low-RAM PIC. If
more space between characters is acceptable, RAM could be saved by
translating on the fly inbetween shifting the pixels for each character out
(or inbetween the date and time, etc.)
The other major problem is to synchronize the PIC's operation to the video
signal so the time display stays at a constant position on the picture. One
method would be to program the PIC to output pulses at the line rate, then
phase-lock the PIC clock so these pulses do occur at the rate of the
incoming horizontal sync pulses. Vertical sync would be with software.
Another method could be a RC or LC oscillator which is forced to start at a
known phase on every sync pulse, but the overall frequency is not critical
or controlled (it would affect only the width and position of the displayed
characters). TV sets which display directly on the screen generally use
this method, although they have a special microprocessor with a video
generator section clocked by its own L-C. Also as it is built into the TV,
it has access to the sweep generator pulse which is a lot cleaner and more
reliable than the sync pulse from the video signal. For this project, it
could be as simple as clamping a L-C oscillator (crystal probably too slow
to restart, and R-C not rated for 12 MHz) off during each sync pulse. This
would be OK for closed-circuit but would probably jitter too much with
over-air signals.
Especially for non-commercial applications, it may be OK to just use a
crystal oscillator running constantly at the 'right' frequency, and let the
text slant and jitter a bit. Obtaining sync by software can be good to one
pixel (do multiple samples), but it might be better to use a larger "window"
and allow the text to drift over a larger range and jump back rather than
jitter rapidly. Overall, not synchronizing the oscillator is not likely to
work very well, especially with low-cost cameras that are likely to not be
very precise in the line rate that they send.
If the PIC's oscillator is allowed to vary, it won't be suitable for
time-keeping. Consider using the RTCC in external mode, either from the
power line if available or a crystal oscillator and divider, as a time base
for keeping the time-of-day. The time and date registers would be updated
during the rest of the video frame, before waiting for vertical sync again.
Polling of the user's inputs would also be done during that time.
> Is the PIC fast enough to be useable as a character generator to
> overlay text/graphics on NTSC video? About 10 chars/line is all I
> need; nothing fancy. (I want to overlay date/time on a camera
> feed.)
Paul:
There's a lot of useful advice in previous replies to your message;
from what others are saying, it looks as though you can do it with a
PIC.
On the other hand, it'd be a whole lot simpler if you used a
microcontroller with TV character-generation hardware built-in. If
you're open to other microcontrollers, try the 6805T-series from
Motorola.
On Tue, 28 Nov 1995, Paul Christenson [N3EOP] wrote:
> Is the PIC fast enough to be useable as a character generator to overlay
> text/graphics on NTSC video? About 10 chars/line is all I need; nothing
> fancy. (I want to overlay date/time on a camera feed.)
>
Hi,
Other postings have suggested that this is possible, and I don't doubt
it. However, ther is a lot to think about in terms of maintaining sync
with the video signal. There is a chip made specifically for this (I'm
afraid I don't know much about it though). There was an article in (I
believe) Radio Electronics-Electronics Now about using this chip a few
years ago. The chip had all the timing circuitry built in and took
serial data (ascii text) to send the character to be displayed.
think using this chip in conjunction with the PIC as a source for the
serial character data might be a simpler way to do the job. At the
least, you could use this chip to get a working system you could reverse
engineer for your final project. Just my two cents. Good luck.
> Is the PIC fast enough to be useable as a character generator to overlay
> text/graphics on NTSC video? About 10 chars/line is all I need; nothing
> fancy. (I want to overlay date/time on a camera feed.)
Fast enough to generate characters? Yes.
Overlay? Yes, but with external hardware. The PIC clock will need to
be synchronized to (a multiple of) the horizontal sync, or you will get
unacceptable jitter in the horizontal positioning of the characters. A
PLL circuit using a 74HC4046 would probably do the job. You'll need a
sync separator to extract the horizontal sync signal from the incoming
video; the canonical chip for this purpose is a National LM1881, but save
yourself some trouble and use the Elantec EL4581 instead. The Elantec
part is a much-improved replacement.
I generate characters on video (but not overlay) in my PIC-Pong (tm) and
PIC-Tock (tm) projects. Information about these, and source code for the
latter, are available from my PIC page on the web:
I get about ten characters per line running the PIC at 18.432 MHz. The
technique used requires all of port B to be dedicated to the video.
You'll also need some code for the PIC to handle vertical synchronization.
My PIC-based closed-caption decoder has code which could be adapted for
that purpose. Documentation and source code are available.
I've started thinking about a closed-caption encoder. The latter will use
basically the same circuitry as a text overlay would require.
My closed-caption decoder originally used a PIC16C61 (or a '71 if you add
code to disable the ADC) and an external dual comparator. Over the recent
holiday Rich and I got it working using the internal comparators of a
PIC16C622.
I recall an article in Circuit Cellar, and source code on their server,
where a clever fellow used a PIC chip to read wind speed/dir, etc.
and simultaneously generate a simple character display video
stream.
You have about 63usec per line, maybe 60% useable is 38usec. On that
you need at least 60 pixels assuming the display is to spread across
the entire screen, so now you have 634nsec per pixel. Even at 20MHz
you are only getting 3 instructions per pixel, not enough to run a
pixel shift algorithm. However, maybe with a external parallel to
serial shift register or for that matter a relatively cheap VRAM....
Rgds, Brian.
______________________________ Reply Separator _________________________________
Subject: PIC and character generator
Author: "Paul Christenson [N3EOP]" <RemoveMEPJC130TakeThisOuTPSUVM.PSU.EDU> at Internet_Exchange
Date: 11/28/95 9:38 AM
Is the PIC fast enough to be useable as a character generator to overlay
text/graphics on NTSC video? About 10 chars/line is all I need; nothing
fancy. (I want to overlay date/time on a camera feed.)
> I recall an article in Circuit Cellar, and source code on their server,
> where a clever fellow used a PIC chip to read wind speed/dir, etc.
> and simultaneously generate a simple character display video
> stream.
Anyone know the details of video time codes as used in production TV ?
I think I have an application for an inexpensive timecode reader
which could perhaps use a PIC and maybe a shift register and sync seperator.
I don't have the spec on the time codes used though. It appears to be time
or date/time as white wide dots in the top line(s) of the video (where
teletext would go), but maybe a microsecond per dot.
> you wrote:
>
> > I recall an article in Circuit Cellar, and source code on their server,
> > where a clever fellow used a PIC chip to read wind speed/dir, etc.
> > and simultaneously generate a simple character display video
> > stream.
>
> Anyone know the details of video time codes as used in production TV ?
> I think I have an application for an inexpensive timecode reader
> which could perhaps use a PIC and maybe a shift register and sync seperator.
>
> I don't have the spec on the time codes used though. It appears to be time
> or date/time as white wide dots in the top line(s) of the video (where
> teletext would go), but maybe a microsecond per dot.
>
There are currently two types of time code used in video. The
traditional type is a serial stream that is recorded either on it's own
track or on an audio track. It has some problems in that it can't really
be read when the deck is in pause and also reading it in reverse is
difficult (although it can be done, and is on high end decks). The type
you are describing is VITC for vertical interval time code. The name
tells you basically what's happening. It solves the problems of
longitudinal time code. A high clock speed Pic could probably pull it
off, but I don't know enough about the timing to say for sure. Try a
search on SMPTE for more info.
> There are currently two types of time code used in video. The
> traditional type is a serial stream that is recorded either on it's own
> track or on an audio track. It has some problems in that it can't really
> be read when the deck is in pause and also reading it in reverse is
> difficult (although it can be done, and is on high end decks). The type
> you are describing is VITC for vertical interval time code. The name
> tells you basically what's happening. It solves the problems of
> longitudinal time code. A high clock speed Pic could probably pull it
> off, but I don't know enough about the timing to say for sure. Try a
> search on SMPTE for more info.
I haven't done anything with VITC, but I have done hardware/software to
read longitudinal timecode and it's not too hard (my software was good for
forward/reverse, approx. 1/4x to 4x speed and probably beyond; the hardware
I was using had an AC coupling cap and a noise filter cap which caused the
signals to wimp out at slower/faster speeds). While it's true that LTC can
not be read while the tape is stopped, it does have a couple advantages over
VITC:
[1] On many machines, LTC and video can be written independently. A VITC
timecode cannot be rewritten without recording over the video.
[2] LTC can be during rapid forward or reverse tape motion without engaging
the video heads.
[3] Since it's nice and slow, a cheap little micro can read/generate it :-)
> Anyone know the details of video time codes as used in production TV ?
> I think I have an application for an inexpensive timecode reader
> which could perhaps use a PIC and maybe a shift register and sync seperator.
Check the article in Circuit Cellar INK issue 45 about the Vertical Blanking
Interval Explorer, one of their design contest winners. The time code was
one of the things the explorer would decode, and there was a description of
the signal format.
The 8051 code for the project and a PostScript version of the original design
contest entry are available from their net server:
ftp://ftp.circellar.com/pub/circellar/INK45/VBI.ZIP
I should add to my previous recommendation about the VBI Explorer published
in Circuit Cellar INK, that the original version didn't actually do
SMPTE VITC, but it did another form of time code used by the networks.
However, the ZIP file that you can get by FTP *does* include a more recent
version of the code which can handle SMTPE VITC also, along with information
on the necessary hardware additions.
PSUVM.PSU.EDU> at Internet_Exchange
