Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
condemned
PostPosted: Jan 26, 2009 - 09:48 AM
Hangaround


Joined: Sep 04, 2007
Posts: 356
Location: Oxford (England)

My 16x2 LCD serial backpack (a great project - thanks microcarl!) is becoming just too small for debugging with, so I've made myself a serial->TV display device. It produces a Black and White PAL composite video signal. It works nicely, but not very brightly.

I used a project at serasidis as the foundation of the circuit. Two output pins ; one sync, one pixel data. The problem is that the 'white' is very 'grey':


I now believe that this circuit shouldn't have the 75ohm resistor in it. The 75ohms is implied at the other end of the cable (inside the TV):


Question 1:
Am I right? Is the second circuit "correct"? In a fit of recklessness, I removed the 75ohm resistor from my circuit and tried it. It produces a much whiter output and the TV hasn't blown up so far. Am I safe, or do I need to check the batteries in my fire alarm?

Question 2:
Are there any simple improvements to the above circuit? It meets my target of 'simplicity', but should I be 'balancing' the signal or anything like that? Do I need a 75ohm resistor in series with the output?
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
emuler
PostPosted: Jan 26, 2009 - 10:11 AM
Raving lunatic


Joined: Feb 07, 2007
Posts: 2395
Location: New Delhi, India

Just do the math. Composite video is a nominal 1.0V pp. 0.3V sync, 0.7V video. Your device is giving 5V pp. The three resistors form a voltage divider.

You're right; the 75ohm inside the TV is implied and present. Some professional monitors have switches at the back for disabling the terminating resistor. If you don't see it assume that the 75 ohm resistor is there.

_________________
If you think education is expensive, try ignorance.
 
 View user's profile Send private message  
Reply with quote Back to top
barnacle
PostPosted: Jan 26, 2009 - 01:48 PM
Raving lunatic


Joined: Jan 03, 2006
Posts: 4770
Location: Hemel Hemsptead, UK

*Strictly* what you should be doing is deriving a 2.0v p-p signal and outputting that through a series 75 ohm resistor from a low-impedance source - a voltage follower or similar.

In practice I do it exactly the same way you did, and tweak the resistors till it looks right. Terminate with the TV's input resistor - but be aware that older TVs may have a live chassis!. The analysis is not as straight-forward as you might think as there are return paths to ground through the resistor which is not being driven...

If you're driving into 75 ohms, using Rsync as 1000 and Rvid as 330 ohms, when vid = 0 and sync = 5v, you're driving into 75//1000 = 61 ohms and the result is 0.28v. When both are at 5v, you're driving 75 ohms from 1000//330 = 248 ohms; result is 1.16v

This version - if I got my sums right! - should have two volts p-p at the base of the transistor, offset by the diode voltage drop to offset the Vbe drop; it *should* give a low-impedance output protected by the 75 ohm in-line resistor into 75 ohms. It assumes a 5v input voltage. Transistor type might want looking at to make sure it has the frequency range; the 2222 was conveniently to hand.

Neil

_________________
Neil Barnes
www.nailed-barnacle.co.uk
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
barnacle
PostPosted: Jan 26, 2009 - 02:07 PM
Raving lunatic


Joined: Jan 03, 2006
Posts: 4770
Location: Hemel Hemsptead, UK

Damn, wrong numbers... RSYNC should be 600 and RVID 240.

_________________
Neil Barnes
www.nailed-barnacle.co.uk
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
bobgardner
PostPosted: Jan 28, 2009 - 03:31 AM
10k+ Postman


Joined: Sep 04, 2002
Posts: 23489
Location: Orlando Florida

So the sync comes from an oc timer out, and the vid comes from the mosi spi out? Then you need to feed the spi every 8 pixel times?

_________________
Imagecraft compiler user
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
emuler
PostPosted: Jan 28, 2009 - 05:03 AM
Raving lunatic


Joined: Feb 07, 2007
Posts: 2395
Location: New Delhi, India

bobgardner wrote:
So the sync comes from an oc timer out, and the vid comes from the mosi spi out? Then you need to feed the spi every 8 pixel times?

If you use the fast SPI code example but slow it down to half speed by adding a nop after each instruction (or 2/3 speed by adding one nop after each pair of instructions) then you can replace every 16th nop (or 8th nop) by a load instruction and keep going without hiccups. Very Happy

_________________
If you think education is expensive, try ignorance.
 
 View user's profile Send private message  
Reply with quote Back to top
bobgardner
PostPosted: Jan 28, 2009 - 05:11 AM
10k+ Postman


Joined: Sep 04, 2002
Posts: 23489
Location: Orlando Florida

Blimey. I knew there was a clever timing trick in there somewhere. I was wondering how to get the next byte loaded in one pixel time.

_________________
Imagecraft compiler user
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
condemned
PostPosted: Jan 28, 2009 - 08:45 AM
Hangaround


Joined: Sep 04, 2007
Posts: 356
Location: Oxford (England)

The advantage of using hardware SPI to control the Pixel output is that whilst it's shoveling bits out, you can retrieve the next byte. That gives you loads of time.

The SPI is still not ideal though.
a) It's limited(!) to 1/2 clock speed
b) you can only load the next byte after 9 bit periods.

The SPI module insists on outputting a 9th idle bit. That idle bit is high and that means an unwanted white pixel in this case. If you attempt to load the next SPI byte before the end of that 9th bit, the new byte is ignored.

The real trick is to switch the MOSI pin to 'input' for the duration of that 9th pixel, removing the ugly white pixel.

If the SPI module is ever revisited by Atmel engineers, a 'no idle' option would be nice Smile - I might be able to embed teletext information into my composite video signal then!
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
barnacle
PostPosted: Jan 28, 2009 - 10:22 AM
Raving lunatic


Joined: Jan 03, 2006
Posts: 4770
Location: Hemel Hemsptead, UK

Agreed. And the chance to load a whole bunch of bytes into it at one hit would make live absolutely peachy - i.e. a hardware buffer with, say, 64 bytes of first-in-first-out... then you could blat a whole line's worth of data at your leisure.

But if we're going to redesign the AVR range, I'd prefer first that they integrate an FT232R into a uart, so it's plug'n'play as a serial link, no messing.

_________________
Neil Barnes
www.nailed-barnacle.co.uk
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
Jepael
PostPosted: Jan 28, 2009 - 10:40 AM
Raving lunatic


Joined: May 24, 2004
Posts: 6229
Location: Tampere, Finland

I never knew the hardware SPI had so many odd quirks in it. So it is definitely not ideal for video generation.

I've seen an AVR generating (black&white) composite video with a shift register like 74HC164 or the like. The AVR loads the shift register via 8-bit bus and load signal, and there is some kind of pixel clock used as the shift clock. Not sure if the load signal was also generated from the shift clock with a divider.

I guess it was like this because the hardware SPI was used as the control interface for the AVR, receiving info what data to display.

This lets the pixels be 8 bits wide, not 9, and it is possible to generate a pixel for every pixel clock instead of every other like with hardware SPI.
 
 View user's profile Send private message  
Reply with quote Back to top
emuler
PostPosted: Jan 28, 2009 - 11:09 AM
Raving lunatic


Joined: Feb 07, 2007
Posts: 2395
Location: New Delhi, India

Quote:

This lets the pixels be 8 bits wide, not 9, and it is possible to generate a pixel for every pixel clock instead of every other like with hardware SPI.

You mean every system clock, I think. If you slow things down, then the pixel clock gets slowed down too.

_________________
If you think education is expensive, try ignorance.
 
 View user's profile Send private message  
Reply with quote Back to top
Jepael
PostPosted: Jan 28, 2009 - 11:33 AM
Raving lunatic


Joined: May 24, 2004
Posts: 6229
Location: Tampere, Finland

That's right. The pixel clock can be the same as system clock.

You could also run the pixels and AVR at separate frequencies, as long as the wanted value is on the bus before loaded. Might be tough to syncronize things then.

But for PAL and NTSC, a single 13.5 MHz clock is enough, as that is the common rate for both. AVRs can't run at 27MHz, which is the usual pixel clock value to get color info there too.
 
 View user's profile Send private message  
Reply with quote Back to top
barnacle
PostPosted: Jan 28, 2009 - 01:31 PM
Raving lunatic


Joined: Jan 03, 2006
Posts: 4770
Location: Hemel Hemsptead, UK

Well, it can be the same as system clock - but you'd be *extremely* constrained in what you can do in the time. I think it takes ten cycles minimum to get a memory byte, index a character font table, and get the byte out somewhere.

_________________
Neil Barnes
www.nailed-barnacle.co.uk
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
condemned
PostPosted: Apr 26, 2009 - 03:56 PM
Hangaround


Joined: Sep 04, 2007
Posts: 356
Location: Oxford (England)

Sorry to drag up an old thread...

For further testing of my TellyMate project (which uses the 2-diode, 2-resistor circuit above), I bought an old 5" portable 12v telly from a car-boot sale this morning (£2 - bargain!).

It didn't work with the TellyMate.

To cut a long story short, it will only work when there's a resistor to ground (as shown in the very first diagram in the thread).

  • 75ohms to ground gives a nice picture with bright whites.
  • 33k to ground gives a picture with muddy grey instead of whites.
  • No resistor causes sync failure, but faint grey pixels can be seen tumbling and rolling.

From these findings, I'm assuming that I've bought a TV without an internal 75ohm resistor.
Other video devices don't have problems with this TV.

Questions:
a) Does my assumption make sense (i.e. this telly has no internal resistor)?
b) How common are these TVs (are all portable TVs like this?)
c) Should I be including an optional [via jumper] 75ohm resistor in my TellyMate kits and TellyMate Shields?
d) Should I really be using a transistor circuit as kindly provided by Neil instead?

Thanks in advance for any insights!
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
Plons
PostPosted: Apr 26, 2009 - 04:34 PM
Raving lunatic


Joined: Nov 01, 2005
Posts: 6597
Location: Hilversum - the Netherlands

Your 5" TVset isn't a professional monitor. It's nice that it has a composite video input though. I created one on a 12" BW TV. Used is as a terminal for my 6502 micro system. Ages ago ...

As for your questions:
a) Unpredictable Wink You cannot be sure, there are so many variations on that theme.
b) See a)
c) Yes, I'd do that
d) That would be the best way to output video, but IMO not an absolute necessaty.

One other thing to consider:
A professional monitor will use the voltagelevel right after Vertical Sync as black level. It's called Back Porch Clamping. But I have seen many monitors that use the voltage level of Vertical Sync as reference for "blacker than black". Called SyncTipClamping. Disadvantage of that method is that black AND white levels change with setting the gain (contrast) to an different level. After contrast adjustment, brightness need to be adjusted as well. And again ....
When the proper method is used, black stays black, and gain influences the white level only.

Nard

_________________
Dragon broken ? Or problems with the Parallel Port Programmer ? Scroll down on my projects-page http://www.aplomb.nl/TechStuff/TechStuff.html for tips
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
Jepael
PostPosted: Apr 27, 2009 - 11:37 AM
Raving lunatic


Joined: May 24, 2004
Posts: 6229
Location: Tampere, Finland

It would be hard to analyze what goes wrong if the picture does not show up.

We'd have to see the timings and voltages of the video signal to proceed. My guess is that there may be something wrong in the odd/even field switching or serration.
 
 View user's profile Send private message  
Reply with quote Back to top
barnacle
PostPosted: Apr 27, 2009 - 07:15 PM
Raving lunatic


Joined: Jan 03, 2006
Posts: 4770
Location: Hemel Hemsptead, UK

One likely possibility is that the input is AC coupled and requires the external resistor to reference the sync tips.

_________________
Neil Barnes
www.nailed-barnacle.co.uk
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
Jepael
PostPosted: Apr 28, 2009 - 09:33 PM
Raving lunatic


Joined: May 24, 2004
Posts: 6229
Location: Tampere, Finland

barnacle wrote:
One likely possibility is that the input is AC coupled and requires the external resistor to reference the sync tips.


But if the TV input is AC coupled, it by definition does not care about DC level fed to it, and should have internal clamp or whatever to get hold of the signal.

Of course depends on implementation, but most inputs just have 75 ohm termination to ground, and then there is the AC coupling. Most video chips I've seen AC couple with only 100nF.

Don't know about typical outputs, as it varies.
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits