I've been researching microcontrollers with the goal of outputting NTSC and/or PAL video signals.

And when I look at the microcontroller specifications, it appears to me that the single most important factor in determining if a microcontroller can generate analog video, is whether or not it has a clock/PLL/timer/counter that can be divided/multiplied such that somehow it is able to output a frequency that matches the required NTSC/PAL video frequency.

And more specifically, it needs the PLL to be fractional so that the clock timers can be divided very precisely because video requires very precise timing.

Is this correct? Am I on the right track, that basically, a microcontroller with a fractional PLL is able to generate NTSC/PAL video, whilst a microcontroller without fractional PLL is not able to generate NTSC/PAL video?

Or do I have it wrong, is the fractional PLL not so important, maybe the required frequency can be generated in some other way that would match the analog frequencies?

Clarification 1:

I am trying to identify, when I look at the specs of a microcontroller, if it is, or is not able to generate an analog video signal. I do understand that many other factors are important in working out if it can do so, but my understanding is, that if you cannot control the output frequency of one of the peripherals to an analog TV output frequency, then nothing else matters - the job cannot be done. I am trying to confirm if my understanding is correct or not.

Clarification 2:

What I am really trying to understand is whether any given MCU can generate the required frequencies without using external components - such as providing an external clock crystal.

Clarification 3:

I'm talking abut generating a composite signal.

  • \$\begingroup\$ It's not clear what you are asking. You ask "a microcontroller without...is not able"...which is asking us to prove a negative and that is impossible. Or are you asking "is the fractional PLL not so important" which is a matter of opinion. \$\endgroup\$ Commented Aug 20, 2020 at 23:46
  • \$\begingroup\$ Apologies. I am trying to identify, when I look at the specs of a microcontroller, if it is, or is not able to generate an analog video signal. \$\endgroup\$ Commented Aug 20, 2020 at 23:54
  • 2
    \$\begingroup\$ The tradional method is to run the µC at a non-fractional multiple of the color clock frequency. That's why crystals at oddly specific frequencies as 14.31818 MHz exist. \$\endgroup\$
    – Janka
    Commented Aug 20, 2020 at 23:58
  • \$\begingroup\$ I think a composite TV signal, especially a colour one, has way too much going on for microcontroller to generate an image in software other than colour bars maybe. \$\endgroup\$
    – DKNguyen
    Commented Aug 21, 2020 at 3:25
  • \$\begingroup\$ @DKNguyen there's many, many examples on the Internet of a wide variety of MCU's generating composite signals including color NTSC and PAL. But not all MCU's can do it. My question is why? How to work out if any given MCU can do that? \$\endgroup\$ Commented Aug 21, 2020 at 3:27

2 Answers 2


Of course not. You always have the option of running the MCU's main clock at the required frequency (or a multiple thereof) so that everything else can be derived by simple counters.

The MCU datasheet will show you the external clock input along with the range of frequencies that you may apply to it. Pick a frequency within that range for your external crystal or oscillator that meets the needs of your application.

For example, a frequency of 14.31818 MHz (4 × the 3.579545 MHz color subcarrier) might be a good choice for generating NTSC video.

MCUs that do serial communication over UARTs frequently run at frequencies like 11.0592 MHz, which is a multiple (6×) of 16 × 115200 Hz that happens to be less than 12 MHz, the upper limit of a common MCU back in the day. If your MCU can do 20 MHz, you might choose 18.432 MHz (10×) instead.

  • \$\begingroup\$ Hmmm OK .... so is this something all microcontrollers can do (or generally speaking, most can do )? In the research I've done it has not seemed evident to me how to precisely set the main system clock to a multiple of the required frequency. What sort of terminiology would I search for in the datasheet to confirm that the clock can manually be set in this way? Thanks! \$\endgroup\$ Commented Aug 20, 2020 at 23:59
  • \$\begingroup\$ Just to clarify ..... you're talking about connecting an external crystal to the MCU to get the desired frequency? If yes that certainly adds to my understanding of the picture thanks, although to clarify further - what I am really trying to understand is whether any given MCU can generate the required frequencies without using external components - I'll update my question. \$\endgroup\$ Commented Aug 21, 2020 at 1:42
  • \$\begingroup\$ The internal oscillators of most MCUs are nowhere near precise enough for this kind of application. \$\endgroup\$
    – Dave Tweed
    Commented Aug 21, 2020 at 1:50
  • \$\begingroup\$ Thanks Dave ..... is there a way to identify if the internal oscillator IS precise enough? Would there be something in the datasheet that would reveal that? \$\endgroup\$ Commented Aug 21, 2020 at 1:57
  • 1
    \$\begingroup\$ @DukeDougal Paper and pencil is how I'd do it. I'd know what I needed to achieve, read the MCU datasheet on its timing systems, and get out a piece of paper, think a little and write stuff down until I was either satisfied there was an approach or else determined it could not be done with the MCU at hand. Study and design precede building/coding and often occupy 70% of the total project time, because once you've worked out exactly how to do things the rest "just flows out." \$\endgroup\$
    – jonk
    Commented Aug 21, 2020 at 4:12

IMHO the primary issue with MCU_hosted PLL and NTSC will be the chroma noise floor.

A constant phase, at the chroma rate 3.579545MHZ, is needed. For 1 degree phasenoise, you need about 1 nanosecond edge jitter.

Assuming a divide_down from 15MHz, the division does nothing to clean up the timing jitter.

So let us compute the amount of GROUND trash, or VDD trash (typical inverter-based oscillator-amplifier circuit has ZERO PSRR), or trash injected via ESD paths, onto the PI_network.

  • Tj = Vnoise/SlewRate.

With +-1volt of oscillation, at 15MHz, the SlewRate is 2 * PI * F * 1 = 100 Million volts per second.

The allowable induced noise (again, on VDD, or on Ground, or onto the PI_output) is

  • Vnoise = Tjitter * SlewRate = 1nS * 100 million volts/second and the Seconds will cancel, leaving

  • Maximum induced trash = 0.1volt

Are you able to achieve that 0.1 volt?


The OP has comment/query about blackwhite TV needs.

Decades ago I worked for 3 years in video and low-band (channel 2-6?) design.

A clean video signal (amplitude information) with 0.7 volts black-white change, needs 40+ dB signal_noise_ratio, or the viewer gets occasional salt-pepper trash in the intensity. That is also a VDD/GND/ESD_Injection/pin_to_pin coupling challenge.

But lets consider the 15KHz synchronization.

The video systems are designed to retain synchronization, to provide a stable image, even if horridly noisy. I had the chance to explore these issues while implementing some downconverters.

I recall even at +10dB SNR there was no framing, no line, synchronization problems.

Why? because the VERY LOW bandwidth of the vertical and the horizontal PLLs.

Let us compute what ZERO dB SNR means, time_wise, for a 1 volt video signal, with 1 volt noise. With 100 nanosecond edges (about duration of ONE PIXEL).

Tj = Vnoise / SlewRate.

We want to compare this to a MCU_based PLL with onchip loop_bandwidth filter.

Tj_video_ZERO_DB = 1volt/ (1volt/100nanosecond) = 100 nanoseconds

I would operate your scope to grab 50 microSeconds of MCU PLL behavior. and examine the cumulative edge time_wander.

The math I've tossed to you, indicates 100 nanoseconds Time_Wander over 50 microSeconds, is acceptable.

SUMMARY: black_white should be OK, but chroma fields will be trashy. IMHO

  • \$\begingroup\$ Is there a way to determine if an MCU is able to even come close to generating a sufficiently precise signal? Can you look at some aspect of its specifications/datasheet and say .... yes this will come close, or not there is simply no way to generate a signal even close to generating a black and white signal, let alone color? \$\endgroup\$ Commented Aug 21, 2020 at 3:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.