Searching \ for 'PIC and character generator' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'PIC and character generator'.

Truncated match.
PICList Thread
'PIC and character generator'
1995\11\28@094137 by Paul Christenson [N3EOP]

flavicon
face
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.)

1995\11\28@122318 by BBoles

flavicon
face
    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_OUTPJC130TakeThisOuTspamPSUVM.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.)

1995\11\28@140339 by Dr Ben Heller

flavicon
face
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).

Ben Heller (.....B.HellerKILLspamspam@spam@Sheffield.AC.UK)

1995\11\28@163949 by John Payson

flavicon
face
> 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.

1995\11\28@164220 by Mike Keitz
flavicon
face
> 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.

-Mike

1995\11\28@183031 by Andrew Warren

flavicon
face
Paul Christenson [N3EOP] <PICLISTspamKILLspamMITVMA.MIT.EDU> 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.)


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.

-Andy

Andrew Warren - .....fastfwdKILLspamspam.....ix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geopages.com/SiliconValley/2499

1995\11\28@192946 by AV Presentations

picon face
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.

morris beverly    EraseMEavpresspam_OUTspamTakeThisOuTworld.std.com

1995\11\29@212704 by Eric Smith

flavicon
face
>"Paul Christenson [N3EOP]" <PJC130spamspam_OUTPSUVM.PSU.EDU> writes:

> 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:

       http://www.spies.com/~eric/pic/

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.

Cheers,
Eric


'PIC and character generator'
1995\12\02@012127 by Steve Childress
flavicon
face
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.

----------
From:   @spam@BBolesKILLspamspamCCMAIL.MICROCHIP.COM[SMTP:KILLspamBBolesKILLspamspamCCMAIL.MICROCHIP.COM]
Sent:   Tuesday, November 28, 1995 9:06 AM
To:     Multiple recipients of list PICLIST
Subject:        Re: PIC and character generator

    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]" <RemoveMEPJC130TakeThisOuTspamPSUVM.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.)

1995\12\02@073456 by adrian

flavicon
picon face
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.

--
_
(_) _| _ . _  _   Tel +44 973 222257
( )(_|(  |(_|| )  Fax UK 0500 222258                    E&OE

1995\12\02@212243 by AV Presentations

picon face
On Sat, 2 Dec 1995, Adrian Kennard wrote:

> 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.

morris beverly    spamBeGoneavpresspamBeGonespamworld.std.com

1995\12\02@224121 by John Payson

flavicon
face
> 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 :-)

1995\12\03@022616 by Eric Smith

flavicon
face
> 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

Eric

1995\12\03@023030 by Eric Smith

flavicon
face
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.

Eric

More... (looser matching)
- Last day of these posts
- In 1995 , 1996 only
- Today
- New search...