How to use smartpin to make 24 MHz?

Has anyone worked out the math?
I need a 24 MHz clock to feed to a camera module...

I'm trying to figure out these SmartPin instructions:
%00110 = NCO frequency

This mode overrides OUT to control the pin output state.

X[15:0] establishes a base period in clock cycles which forms the empirical high and low times.

Y[31:0] will be added into Z[31:0] at each base period.

The pin output will reflect Z[31].

IN will be raised whenever Z overflows.

During reset (DIR=0), IN is low, the output is low, and Z is set to zero.

I guess it wouldn't be too hard if period were even number of clocks, but I need a period of 3-1/3 clocks...


  • Start_Xclk 'thank you Ozpropdev!!!
    WRPIN #%1_00110_0,#_Xclk
    WXPIN #1,#_Xclk
    qfrac ##xclk_freq,##sys_clk
    getqx pa
    WYPIN pa,#_Xclk
    dirh #_Xclk
  • not sure this works for 24MHz... Using an 0v7670, which is supposed to give a frame rate as a function of clock frequency everything is ducky right up to 20MHz and then it isn't.

    this code for the ov7670 and ov7675 works at 20MHz but not for 24MHz... I went back to the 120MHz P2 version, it didn't work either ... but not sure if that was before or after I damaged my poor little P123... such a nice board:(

  • Thanks! I'll give it a try. I can check with scope...
  • I love the 7675, but I'm convinced that the ones floating around on the internet are spoils. The data sheet says that there is 8 pixel padding on either side of href, but I'm convinced that the pixel arrays on all my boards include the padding and skips some active pixels. As though someone miscalculated an offset. There is also an issue with the size of the pixel array... If I try to get all 480 lines, then the Vsync gets missed... 479 works. It may be my code... and maybe I have stared at it too long.

    This code works around the issues.

  • Thanks, I'll check it out.
    Looks like you beat me to it...
  • I need to check the 24 MHz at work with a better scope.
    Seems to be too fast for my scope at home...
  • Here's the 24 MHz version:
    640 x 480 - 18K
  • evanhevanh Posts: 10,088
    edited 2017-11-25 - 00:03:46
    It'll be alternating between 4 sysclocks for 20 MHz and 3 sysclocks for 26.6667 MHz. The average frequency is bang on ... but not much good for a stable digital clock.

    Is 26.6667 MHz close enough?
  • RaymanRayman Posts: 11,495
    edited 2017-11-25 - 00:02:23
    Eeek! That's no good. I think it violates the clock duty cycle spec... Maybe that's why rjo__'s works at 20 MHz and not 24 MHz...

    20 MHz is good enough, I think...
  • Rayman wrote: »
    Eeek! That's no good. I think it violates the clock duty cycle spec...

    Ah, I have an idea, it's likely to be just the variance in the rising times rather than duty as such ... With some experimenting I see even this idea needs the duty (instead of frequency) mode set:
    Start_Xclk              'thank you Ozpropdev!!!
                        WRPIN #%1_00111_0,#_Xclk
                  	    WXPIN #1,#_Xclk
                        qfrac ##26_666_667,##sys_clk
                        getqx   pa
                        WYPIN pa,#_Xclk
                        dirh #_Xclk
  • Here's 26.667 MHz in duty mode, I think it'll work fine.

    And here's 24 MHz in duty mode. It's cleaner than frequency mode but still no good for steady clocking:
    640 x 480 - 19K
    640 x 480 - 19K
  • Actually, neither of those modes are desirable. They are only meant to be used for averaging the pulse rate.

    The better mode is PWM sawtooth mode (%01001). It is defined in terms of the number of clocks for the period. There's no accumulative rollover happening:
     		dirl    #tpin                     ' Disable Smartpin while setting up
    		wrpin   #%01_01001_0, #tpin       'PWM sawtooth mode
    		wxpin   ##$30001, #tpin           ' 3 sysclocks for period = 26.667 MHz
    		wypin   #2, #tpin                 ' Duty is 2 high, 1 low
    		dirh    #tpin                     ' Enable Smartpin
    		jmp     #$
  • It's a pity the fractional clock feature of the aysnc serial modes can't be used in some way for a tighter NCO frequency mode.
  • jmgjmg Posts: 14,540
    ozpropdev wrote: »
    It's a pity the fractional clock feature of the aysnc serial modes can't be used in some way for a tighter NCO frequency mode.

    The edge placement is always going to be SysCLK granular, no matter what clock derivation is used.
    I think the Serial modes restart on every frame, to avoid the 2^32 round-over effect NCO otherwise has.
    ie NCO does not actually give precisely 24MHz,

  • evanhevanh Posts: 10,088
    edited 2017-11-25 - 07:11:51
    Wow, what a mode! It's not doing the impossible but a valiant effort for async comms. It is throwing intentional jitter, a dither I guess, into the bit timing to keep it evened out.

    Locking onto it with the scope was weird. It can look surprisingly clean with overlaid waveform averaging turned on. Worst case is not surprisingly at the fastest clock rates. Top limit is 40 Mbit/s on 80 MHz sysclock - which can then emulate up to a 20 MHz clock.

    The commented out 48 Mbit/s line produced a solid 80 Mbit/s rate (clean 40 MHz waveform).

    Here's my test source code:
    		waitx   one_sec
    'set mode of Smartpin
    		dirl    #tpin                     ' Disable Smartpin while setting up
    		wrpin   #%01_11110_0, #tpin       'Asynchronous serial transmit
    '		mov     parm, ##$1A800            ' bitrate = 48 MHz = (1.666667 * $1_0000) & $FFFFFC00
    		mov     parm, ##$35400            ' bitrate = 24 MHz = (3.333333 * $1_0000) & $FFFFFC00
    '		mov     parm, ##$20c00            ' bitrate = 39 MHz = (2.051282 * $1_0000) & $FFFFFC00
    		or      parm, #$1F                ' 32N1 protocol
    		wxpin   parm, #tpin
    		call    #itoa
    		call    #putnl
    		dirh    #tpin                     ' Enable Smartpin
    		mov     parm, ##$55555555         ' Emulate clock pattern
    		wypin   parm, #tpin
    		testp   #tpin      wz
    if_z	wypin   parm, #tpin               ' Keep feeding the serial port with more emulated clocks
    		jmp     #.peas

    Here's a 24 Mbit/s output ( emulating a 12 MHz clock). This screenshot is with waveform averaging enabled to clean up the jitter. It looks very stable like this but you still get to see where the jitter is though, the stepped notches in the waveform is how far the jitter fluctuations are moving.
    640 x 480 - 19K
  • evanhevanh Posts: 10,088
    edited 2017-11-25 - 10:35:03
    Bah! The async serial pacing is the same NCO function as the opening 24 MHz except it can't go that fast so it's not as obvious.

    It doesn't take that much of a down clock for NCO to look okay for databus operations. EDIT: That doesn't mean it is okay though. Eg: The camera probably uses the clock internally and needs it stable more than a particular frequency.

    On the flip side, async serial never locks to a clock so dithering the bitstream is perfectly viable.
  • Some NCOs offer a second, tuning parameter to add another factor into the counting.
  • @rjo__

    I tried your above code I get loading errors. Am I missing something?
    968 x 811 - 52K
    791 x 856 - 47K
Sign In or Register to comment.