How to use smartpin to make 24 MHz?
Rayman
Posts: 14,646
in Propeller 2
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:
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...
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...
Comments
WRPIN #%1_00110_0,#_Xclk
WXPIN #1,#_Xclk
qfrac ##xclk_freq,##sys_clk
getqx pa
WYPIN pa,#_Xclk
dirh #_Xclk
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:(
This code works around the issues.
Looks like you beat me to it...
Seems to be too fast for my scope at home...
Is 26.6667 MHz close enough?
20 MHz is good enough, I think...
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 retAnd here's 24 MHz in duty mode. It's cleaner than frequency mode but still no good for steady clocking:
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:
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,
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:
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.
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.
I tried your above code I get loading errors. Am I missing something?
Has anyone gotten this to work?
I don't need the bitmap, but there are issues with the sample code:
(1) clkset isn't a valid op, what do I use instead?
(2) What pins are used to connect to the VGA monitor? My understanding is that I need 8 pins to drive the VGA signals.
I have a modified driver that uses a 4 pin boundary for HS, B, G, R and VS is 1 pin below the 4 pin group. So it uses the upper 5 pins of an 8 pin group.
Probably best to look at the VGA demos downloaded with pnut.
https://forums.parallax.com/discussion/172393/nco-square-wave-output-using-smartpin
becomes this:
Cheers Bob G4BBY S.W. UK
I did some revised / improved code on the Si5351, as most every example on the Internet and even the manufacturer were either wrong or incomplete. Going thru every single rule and register, I have a rather complete PUB functions. You need a good 64-bit SPIN2 multiply & divide function to do it right because you are taking the answers out to the last digit & errors crop up. Plus you do not want to take any short cuts in the code because you never know when a register will change. The P2 is so fast you can calculate each and every frequency change in real time, you never notice any jumping or anything. I gave up on the Si5351 because the smallest increment is at least 100 Hertz, not good for radio work. I will post what I have later.
Currently I am using the much better Si570 synth chip. Again most every example on the Internet is wrong or incomplete including the example on SI website. I do a complete recalculation ( Micro-seconds ) for every frequency change, because you really never know when a register will change - The register math is something else!!! You need a really good SPIN2 64-bit Multiply & Divide function to get it right. I will share the PUB functions later.
The Si5351A can end up using quite large integer-fraction ratios for the M feedback, and that could give more spurs ?
The Si570 has much higher VCO ( ~ 5GHz) than Si5351 (600~900MHz) so it will have better spectrum - but the mature Si570 comes only in 5x7 cases.
The Si514 is between the two, with lower Icc and smaller packages than Si570, and similar jitter specs to Si570.
The Si549 has ~ 11GHz VCO and even lower jitter than Si570, but there seems less info out there on Radio use examples of Si514 or Si549.
Stocks are showing of Si514 & Si549.
The Si570 is a good choice all around for RF circuits. The 5x7 footprint is doable on a PCB. The frequency resolution is good - if you can get past the register math. It took me a couple of weeks to figure it out LOL Other synth chips are out there but I need something reliable that I can work with - and not spend days or weeks plowing thru bad documentation and poor code examples.
Between 100 - 50Hz resolution? - Do you mean you cannot tune the SI5351 in less than 50Hz steps or that frequency accuracy is more than 50Hz adrift at certain frequencies?
I've been checking my set up with an old Racal frequency counter which limits measurements to 30MHz. After correcting the crystal frequency constant in the software, o/p accuracy varies with demanded frequency and PLL frequency setting, but seems better than 10Hz. I was having too large step size issues at one point. I wrote a check function that calculated the output frequency from the params A,B,C etc which revealed a maths error. After fixing that, the chip tuned smoothly in hardly discernible increments, when monitored in a receiver. The check frequency was at worst 4Hz away from the demanded frequency, worst case being at the 120MHz end of course. Precision seems to be OK with me, at least. One of my functions uses a 64 bit intermediate value in a multiply-divide step too.
My listening experience over several years with a Proficio sdr tuned with an SI5351 has been very good with regard sensitivity, selectivity and lack of spurs (much fewer spurs than the DDS tuned Flex 3000 ), so for me SI5351 performance seems good enough. The SI5351 is operated in the frequency range 6-120MHz, with an external divide by 4 to drive a tayloe mixer with quadrature signals at 1.5 - 30MHz. I also note Elecraft have designed the SI5351 into their KX2 and KX3 radios which are well respected. Both these applications are different from a superhet with 45MHz IF of course, especially if the LO is set on the high side, so you'd need the SI5351 to tune 46.5 - maybe 75MHz? I can see how the SI570 might start to pull ahead on performance in that range.
"you never know when a register will change" Agreed, they change in a complicated way. I save a few key parameters from the last cycle and compare them with the newly calculated parameters as I'm writing to the SI5351. If the new and old byte are the same I don't resend it. Sending an i2c byte is relatively slow, so I've chosen to avoid it - the aim being that whilst tuning around with a rotary control, a lot of the time only 1 to 3 bytes need sending every frequency change. I haven't completed it yet - and it'll be worth comparing the tuning rate with that and more simple register loads. The added logic may take longer (in forth) than a more simple load, we shall see.
All the best with your receiver project, of course.