Can I send XINFREQ directly to a pin?
brianm734
Posts: 29
Hello,
I'm new to Spin. Is it possible to send the XINFREQ or CLKFREQ directly to a pin? So if I have a 5MHz crystal, I could get a 5MHz square wave output on a pin? I know I can have a cog synthesize this frequency and output it on a pin, but I'm interested in using clock sources other than a crystal, like a rubidium reference, or modelocked laser oscillator, and I need (along with a synthesized frequency) a pass-through clock signal with known phase delay.
Thanks
I'm new to Spin. Is it possible to send the XINFREQ or CLKFREQ directly to a pin? So if I have a 5MHz crystal, I could get a 5MHz square wave output on a pin? I know I can have a cog synthesize this frequency and output it on a pin, but I'm interested in using clock sources other than a crystal, like a rubidium reference, or modelocked laser oscillator, and I need (along with a synthesized frequency) a pass-through clock signal with known phase delay.
Thanks
Comments
-Phil
Does anyone have experience with using an external XIN clock source, and then using the PLL and a cog to synthesize harmonics / sub-harmonics of the XIN frequency? How stable is the signal generated? What phase jitter can I expect?
Thanks.
-Phil
It appears I can just set the _clkmode = xinput and use my external clock from DC to 80MHz (possibly up to 100MHz) without the PLL.
I would like to do a simple 16 bit divider (divide by 1,2,3...65535) for my first project (other than the Propeller Education Kit projects). I would start with a simple 16 IO line parallel dip switch setup at first, and go from there.
Thanks.
In the context of but I'm interested in using clock sources other than a crystal, like a rubidium reference, or modelocked laser oscillator probably more than you would like.
This will depend on the PLL jitter, and also what else the COGs are doing and driving & if the Video PLL is active too...
You are probably best measuring it.
You can get a buffered x1 Output on XOUT pin, if you configure as a Crystal but still drive externally.
-Phil
I am new at this, so forgive any dumb questions.
-Phil
repeat
outa[pin] := 1
waitcnt(clkfreq/wordvariable + cnt)
outa[pin] := 0
waitcnt(clkfreq/wordvariable + cnt)
Remember - I'm new at this.
Right now I'm using four 74LS163's and some NAND gates to do my 16bit divider. This is trivially implemented in an FPGA, but I would like to see if it possible to do in Spin on the Prop.
loop or outa,pinmask nop nop nop andn outa,pinmask nop nop jmp #loop pinmask long 1 << PIN_NUMBERThat would be the worst case for an integer divide.
In any event, you don't need to involve an external pin. Just use the system clock as your reference.
-Phil
Yes, that would work, but as Phil cautions, it has a software-speed determined frequency ceiling.
There is another thread on precise timing that may give some info :
http://forums.parallax.com/showthread.php?138461-200kHz-5kHz-pulse-output
The adder topology of the Prop counter has high precision, but it does have a jitter/rounding error.
Because you can access both registers, you can do some software fixups. I think I've seen examples on here, but forget the headings.
I think you may be able to use two counters, one in NCO mode, and another to manage the creep-correction.
If we take an example, of 80MHz / 20,000, that is going to need an ideal adder of
2^32/20000 = 214748.3648
but you can add only integers, so get
2^32/214748 = 20000.0339747 adds per overflow, or a Fo long term average of 3999.993205070
ie most cycles will be 80e6/20000, but every ~29 output cycles, one more add will be needed, so instead of the 4000.00Hz,
that cycle will be 3999.80000999Hz, for a long term average 3999.993205070
The creep value is
2^32-(20000 * 214748) = 7296 - this is how much the adder is 'short' by, and this drives the occasional /20001
7296/214748 = 0.0339747 1/ans = 29.433662280 output cycles repeat rate.
If you can manually add 7296 counts per output cycle, (and you have 29 cycles to do this, for this example) then you can correct the creep and you will get 250us outputs.
If a second counter collects cycles, you can wait for (say) 10 cycles, and then add 72960 ( minus a small delay fix, plus whatever add's would have occurred in that time).
At the other end of the scale, look at /5, this is close, but gives average of
80e6*round(2^32/5)/2^32 = 15999999.99627Hz
2^32-5*round(2^32/5) = 1, so you need to add one rarely, to avoid the rare case where one /6 occurs.
Hopefully this can reduce to a general case
Edit : I had time for a deeper search and there are some caveats in 'correcting the adder'
- examples
http://forums.parallax.com/showthread.php?105652-Read-modify-write-on-PHSx-not-supposed-to-work-but-does.&p=742808&viewfull=1#post742808
- but because this adder-fix is not needed that often, in a time sense, (and not needed at all in the 2^N cases) I think this avoids the Ceiling issues of a software-paced divide. You do need a second counter to track how many cycles have gone, to pace your correction. Not trivial.
Or a CPLD ?
This might be easier in a Prop 2...
If you want general frequency control, look at the Silabs Si5351A
That's not quite what I need. My clock source is a modelocked laser. It's frequency drifts with temperature, and I have no control of its phase. So I need two synchronous pre-settable binary counters in series (like On-Semi / Micrel SY10E016), or a DDS (like Analog Devices AD9851) with my laser's photo-diode signal as the master clock. In this case I could only select exact sub-harmonics of the master clock because the divided master clock rate drives my acousto-optic modulator, which picks optical pulses out of my laser pulse train. The DDS signal phase can be controlled to to allow AOM RF to optical timing adjustment.
The PLL's in the Prop won't work in this case because my clock frequency is too high to use with the Prop PLL. I can't divide the laser clock down first, because it would limit my maximum optical rep-rate.
Anyway, I can control some other device with the Propeller to get the job done.
Thanks.
Probably a good idea, to at least get something working.
If you are all done, and find you have a spare COG, someone on here may have worked out a general case (or remembered a link to exactly the right answer)
- the link I've added above show Phil was working on similar 'live adder adjustments' in 2008.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 PIN_NUMBER = 1 N = 10 'N must be greater than 2. PUB start n0 := (N - 2) * 2 cognew(@div_by_n, 0) DAT div_by_n or dira,pinmask loop or outa,pinmask mov acc,n0 djnz acc,#$ nop andn outa,pinmask mov acc,n0 djnz acc,#$ jmp #loop pinmask long 1 << PIN_NUMBER n0 long 0-0 acc res 1For N == 2, use the example code I gave above.
-Phil
The PASM loop uses the PLL, and divides after a x16. That may be enough ?
Did you get any further with the example I found from you ~ 2008, of doing :
(renamed for clarity)
add frqa, NudgeValue_Div4 ' 4 adds will occur in the time of this opcode
sub frqa, NudgeValue_Div4 ' back to dominant adder value
I think such an approach should allow external clock to 80MHz, divide by 3,5,7.. as well as the 2^N cases HW supported.
So 40MHz, 26666666.66' MHz , 20MHz, 16MHz, 10MHz, 13333333.333'MHz , 11428571.428MHz etc ?
If there is no general case, then perhaps a SW loop for large N, (>= 48) and Sw assisted HW for low values of N ?
Thanks.
That example was meant more for phase shifting/modulation than for frequency setting. The example I gave above will divide the system clock/16 by any integer from 3 on up. (I'm sure Kuroneko will be able to generalize it to 2 on up.
-Phil
Is the PLL something that you need to avoid for some reason?
-Phil
Cripes, there's a lot of uncatalogued knowledge on this forum!
-Phil
Ah.. That was one I was trying to find...
I don't really need to avoid the Prop PLL other than the Prop data sheet says the maximum xin frequency is "4-8MHz" when the PLL is used. I imagine I can push that to 10 or 12MHz, but I think 25MHz would be too high. Otherwise I would just set PLL4X, and my clkfreq would be 100MHz.
Thanks
-Phil
Yes, but it can also be used to remove the creep offset from the Adder.
Result is quite similar to the looping-re-load of PHSA that kuroneko outlines here :
http://forums.parallax.com/showthread.php?133741-FYI-clkfreq-2n&p=1027071&viewfull=1#post1027071
That also removes phase creep, by virtue of the hard reset per loop, but because the FRQx adder fix in your example does not need to be applied at high speeds, you effectively get part of a COG back - ie it uses less resource.
To some users, that may be important.
At low divide ratios, because the larger adder values can be quite close to ideal, it takes quite a while for the error phase to hit the bonus-swallow case.
The first /2../27 for example, I find no creep times under 2.440 seconds.
Even up to /512, there is no creep time under ~ 111ms, and up to /100, not under 559ms.
As in the other threads, usually you flip to software waits at lower output rates, but as there is now 'room for other code' that cross-over may not be the around /27 of a tight PASM loop.
I wonder what the cycle count of this in Spin is ?
add frqa, NudgeValue_Div4 ' 4 adds will occur in the time of this opcode
sub frqa, NudgeValue_Div4 ' back to dominant adder value
It works (in my experiments) even with 14 MHz quartz. PLL was 14x16=224 MHz and the Propeller was overclocked to 112 MHz. And you can find my experimenal audio driver which uses pll @ 224 MHz, too, with non-overclocked Propeller
I tried 16 MHz with no success. 256MHz was too much for Propeller's PLL
Xin=25 and clkfreq=100 will not work, because xin is as default multiplied by 16, and then divided by 4. So when xin=25, pll will try to work @ 400 MHz, which is impossible. Its real maximum available frequency is something about 240 MHz.
This limits crystal frequency to 14..15 MHz if you want to use xin+pll as a clock source. With higher frequency crystals you have to switch pll off.
And because of this, combination like this:
using 20 MHz crystal, will not work, because pll4x is in reality pll16x/4 and pll cannot run at 320 MHz.