PROPetual Commotion
Phil Pilgrim (PhiPi)
Posts: 23,514
AKA self-referential timing:
I know this is weird, but I just had to try it. The idea is that you overdrive XIN, in XINPUT | PLLx? mode, forcing the system clock's VCO to run at its open-loop frequency. You do this by making one of the counters do the same and using its output to drive XIN. The program has to start in RCFAST mode first in order to get everything set up and the counter running. Then you can shift gears to XINPUT | PLLx? I started with PLLx16 and got a system clock frequency of about 250 MHz. The counters ran okay, but the program would not. By backing down to PLLx8, I was able to get a program running with a system clock frequency of 125 MHz -- all without any external clock sources or resonators. Here's the test program:
Here's the scope output:
The top (yellow) trace is XIN (i.e. ctra); the middle {cyan} trace, the output of ctrb; the bottom (magenta) trace, the output of the PASM program.
Of course, this is not something you'd do if you need any kind of timing accuracy.
-Phil
I know this is weird, but I just had to try it. The idea is that you overdrive XIN, in XINPUT | PLLx? mode, forcing the system clock's VCO to run at its open-loop frequency. You do this by making one of the counters do the same and using its output to drive XIN. The program has to start in RCFAST mode first in order to get everything set up and the counter running. Then you can shift gears to XINPUT | PLLx? I started with PLLx16 and got a system clock frequency of about 250 MHz. The counters ran okay, but the program would not. By backing down to PLLx8, I was able to get a program running with a system clock frequency of 125 MHz -- all without any external clock sources or resonators. Here's the test program:
CON
_clkmode = rcfast
CLKPIN = 0
MONPIN = 1
PRGPIN = 2
PUB start
ctra := %00010 << 26 | %111 << 23 | CLKPIN
frqa := $8000_0000
dira := 1 << CLKPIN | 1 << MONPIN
frqb := $8000_0000
ctrb := %00100 << 26 | MONPIN
waitcnt(cnt + clkfreq >> 3)
clkset(%0110_0110, 0)
cognew(@monitor, 0)
repeat
DAT
monitor mov dira,pinmask
main_lp mov outa,pinmask
nop
mov outa,#0
jmp #main_lp
pinmask long 1 << PRGPIN
Here's the scope output:
The top (yellow) trace is XIN (i.e. ctra); the middle {cyan} trace, the output of ctrb; the bottom (magenta) trace, the output of the PASM program.
Of course, this is not something you'd do if you need any kind of timing accuracy.
-Phil
320 x 282 - 13K
640 x 480 - 18K
Comments
Where to you get these ideas ???
I assume you must connect P0 to XIN for this to work ?
This could be really useful where you need more speed than RCFAST and don't need accuracy.
P.S. I wonder what the low end clock speed of the VCO is ?
Bean
I doubt that there's any way to adjust the clock speed, since you're relying solely upon the open-loop frequency of the VCO. Assuming that were dependent only upon temperature, a thermistor might provide a clue as to what the actual speed is. Realistically, it's probably also device-dependent and who-knows-what-else-dependent. The phase of the moon, perhaps?
-Phil
I have thought of using external environmental influences to affect the clock, but haven't really implemented anything. Basically a reverse method of timing something. Normally you would have a fixed clock frequency monitoring an I/O pin and timing the event on the pin. The reverse method would be to have a 'fixed' clock frequency or event on an I/O pin to monitor the system clock timing.
As far as "could the temp be monitored with say a thermistor and the clock adjusted accordingly" - A thermistor tied to a VCO supplying the clock input would do that.
If only you could do this with power too... Like the perpetual power idea of inserting the power plug of a plugboard into the first socket
Humanoido brings up a good point about making a demo which doesn't require an oscilloscope to monitor the speed change.
This demo doesn't "count a number range" but it does use a waitcnt to wait a predetermined number of clock cycles.
CON _clkmode = rcfast CLKPIN = 0 LED_PIN = 16 ESTIMATED_HZ = 125_000_000 TOGGLE_WAIT = ESTIMATED_HZ / 4 ' to flash LED at approximately 2 Hz SLOW_TOGGLES = 10 ' five flashes FAST_TOGGLES = SLOW_TOGGLES PUB Start dira[LED_PIN] := 1 Toggle(SLOW_TOGGLES) ctra := %00010 << 26 | %111 << 23 | CLKPIN frqa := $8000_0000 dira[CLKPIN] := 1 waitcnt(cnt + clkfreq >> 3) clkset(%0110_0110, 0) Toggle(FAST_TOGGLES) reboot ' go back to rcfast mode PUB Toggle(timesToToggle) | timer timer := cnt + TOGGLE_WAIT repeat timesToToggle !outa[LED_PIN] waitcnt(timer) timer += TOGGLE_WAITThe above demo flashes a LED five times at the rcfast clock speed and then five more times at the approximate 125MHz clock speed. It's kind of fun to see how dramatic the difference is between the two clock settings.
I removed the PASM code and extra pins to simplify the program.
I'm attaching this demo and the original code as Spin files.
My original cut and paste left out some characters because of the percent signs. Hopefully this Spin code will make it easier for other to try out this cool new trick.
I'm wondering since pin P23 is physically so much closer to XIN, do you think there would be any issues with the whole "Cog and I/O Pin Relationship" delays? It looks like using cog 7 would be ideal in this case, possibly forcing even purists to start off with a COGINIT? [8^)
Jonathan
Can the code be made more simple?
1) Turn on high speed rc clock (first section of the code)
2) Run program below (other section of the code)
Yes, of course. Though technically the timing isn't as exact since the setup isn't included in the delay (I doubt the difference would be noticed).
I also thought it would be interesting to compare the rcfast speed vs the PROPetual speed Prop so I make the flashing part of the code a method which may be called while the Prop is operating at the two different speeds.
Edit: See Phil's note below about clkfreq. I wasn't sure what the value of clkfreq would be which is one reason I didn't use it in my LED demo.
How to fix the delay for faster blinking?
CON ' Constants CLKPIN = 0 ' connect clock pin P0 to XIN LED_PIN = 15 ' put LED on pin 15 PUB Start ' Block to start PROPetual Speed ctra := 010 << 26 | 1 << 23 | CLKPIN ' frqa := $8000_0000 ' frequency dira[CLKPIN] := 1 ' make CLKPIN output to XIN waitcnt(cnt + clkfreq >> 3) ' Pause clkset(10_0110, 0) ' Toggle ' Run Toggle PUB Toggle ' Block to Toggle LED dira[LED_PIN] := 1 ' Set LED pin 16 to output repeat ' Loop below !outa[LED_PIN] ' Toggle pin 15 /true/false/ waitcnt(clkfreq + cnt) ' Delay-Phil
Wow - that worked! Yes it was about 53 seconds.
Could you explain what's happening here?
-Phil
I thought I had in post #8.
Watch out about the percent sign causing trouble with cut and paste.
I might work if you use an "auto-baud" type setup. Where the other device sends data first. Then the propeller can time that data and use that timing to send data back.
Bean
How about autosynch the self reference clock to the external source clock? And then make it an external synchronous?
We did have an autobaud (on the Harris RTX2000) that could sync in one character. I have a gut feeling about this. Maybe too much coffee.
Why wouldn't a program run at 250MHz and are there any mods that could make it run that fast? Maybe another weird thing?
This is seriously cool!
Thanks for the link in the other thread, I missed this thread somehow.