Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

PAL vs. NTSC

Status
Not open for further replies.
blueroomelectronics said:
Point is crystals come in many frequencies, why would you use something like 20MHz when you could use something that's a better fit for the job at hand?
I get your point, but I guess I was figuring that if I was trying to do this with a 16F88 or such, and the fastest it'll run is 20MHz, that I'd get a better resolution with a faster chip? I mean, it might not divide neatly into the NTSC standard, but given the suggested leeway for horizontal sync times, that might not be an issue. Personally, I'm not worried about the NTSC police telling me it doesn't conform exactly to the standard - I'm just a tinkerer trying to make the most of what I've got.

Yes, as long as I'm studying and learning I appreciate the value in conforming to the standards and products normally associated with certain applications, but on the other end of things, I think there's some value to trying to explore what can be done with the tools most readily at the disposal of mcu novices. If that can be an entry point to those novices choosing a direction to their liking that's faster, bigger, etc, so be it.
 
Point is crystals come in many frequencies, why would you use something like 20MHz when you could use something that's a better fit for the job at hand? Try digikey for some common frequencies.

I guess I don't understand why you think the odd freqeuncy is "better fit" for the job when when anyone should be able to generate a 63.5 usec scan line with almost any Fosc.

I cobbled together an isochronous loop below to work out timings. It seems I should be able to paint 120 lines of 256 dots (200 nsecs per dot at 40 MHz) or, probably better, 240 lines of 128 dots (400 nsecs per dot at 20 MHz). ** this is not working code, just a timing exercise...

Mike
Code:
;
;  assuming RA0 connected to resistor(s) to produce the 0.0/0.3v
;  level and RB0 connected to resistor(s) to produce the 1.0v
;  level.
;
;  the first 2 delays would be used to stuff the 32 byte work
;  buffer.  The 588 cycles available in each of the 20 vertical
;  sync' lines would be used for updating the video buffer.
;
frame
        movlw   242             ;
        movwf   hctr            ; set horizontal line counter
hline
        bcf     LATA,0          ; 00.0 usecs - set 0.0v 'sync' level
        DelayCy(47)             ; "sync"
        bsf     LATA,0          ; 04.7 usecs - set 0.3v 'blk' level
        DelayCy(57)             ; "back porch"
B00     movf    POSTINC0,W      ;
        movwf   LATB            ; 10.6 usecs
        nop                     ;
        rrcf    LATB,F          ; 10.8 usecs
        nop                     ;
        rrcf    LATB,F          ; 11.0 usecs
        nop                     ;
        rrcf    LATB,F          ; 11.2 usecs
        nop                     ;
        rrcf    LATB,F          ; 11.4 usecs
        nop                     ;
        rrcf    LATB,F          ; 11.6 usecs
        nop                     ;
        rrcf    LATB,F          ; 11.8 usecs
        nop                     ;
        rrcf    LATB,F          ; 12.0 usecs
;~~~~~~~
B01..B30 ; same code for bytes 01..30
;~~~~~~~
B31     movf    POSTINC0,W      ;
        movwf   LATB            ; 60.2 usecs
        nop                     ;
        rrcf    LATB,F          ; 60.4 usecs
        nop                     ;
        rrcf    LATB,F          ; 60.6 usecs
        nop                     ;
        rrcf    LATB,F          ; 60.8 usecs
        nop                     ;
        rrcf    LATB,F          ; 61.0 usecs
        nop                     ;
        rrcf    LATB,F          ; 61.2 usecs
        nop                     ;
        rrcf    LATB,F          ; 61.4 usecs
        nop                     ;
        rrcf    LATB,F          ; 61.6 usecs
;~~~~~~~
        nop                     ; 61.7 usecs
        nop                     ; 61.8 usecs
        movlw   20              ; 61.9 usecs
        movwf   vctr            ; 62.0 usecs
        clrf    LATB            ; 62.1 usecs - set 0.3v 'blk' level
        DelayCy(14-3)           ; "front porch"
        decfsz  hctr,F          ; 63.2 usecs - 242 lines?
        bra     hline           ; 63.3 usecs
        nop                     ; 63.4 usecs
vsyn1
        bsf     LATA,0          ; set 0.3v level
        DelayCy(47-1)           ; inverted "sync"
        bcf     LATA,0          ; set 0.0v level
        DelayCy(588-4)          ;
        decfsz  vctr,F          ; all 20 vsync lines?
        bra     vsyn1           ; no, branch, else
;
;  the vsyn1 code needs to be modified to jump to "frame" (a
;  new frame) with the correct timing...
;
 
The tradeoff is accuracy. A crystal is more accurate than a simple resonator.
And the only advantage to using an oscillator over a crystal is that they're capable of higher frequencies. Given their use for PICs, however, I see the crystals go up to 80MHz from digikey, which appears to far exceed the maximum frequency for any of the PICs I've been using. I can't see the point in using an oscillator for a PIC, given oscillators appear to be more expensive and cumbersome, but maybe I'm missing something here?
 
Last edited:
An advantage of a resonator may be built in caps, cheap, and shockproof (crystals are not happy about shocks)

The 14.31818 will get divided by 4 by the PIC, that will make it less than ideal for a 910 division (TMR2)
So the magic crystal frequency will be something that multiplies by 62937.0549Hz the closer to 20MHz the more breathing room you'll have.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top