Changing prop speed at runtime?
__red__
Posts: 470
I want to bigbang VGA if a user does some kind of "secret interaction" with the badge.
The badge currently runs at 40Mhz. VGA requires 80Mhz in every version I've seen. Is it possible to up the clockspeed at runtime (with the understanding that I would have to account for that in other areas of the code).
If not at runtime, could I conceivably modify the image in the eeprom and do a hard-reset? Is that part of the image documented somewhere?
We're running at 40Mhz to try and conserve battery.
Thanks,
Red
The badge currently runs at 40Mhz. VGA requires 80Mhz in every version I've seen. Is it possible to up the clockspeed at runtime (with the understanding that I would have to account for that in other areas of the code).
If not at runtime, could I conceivably modify the image in the eeprom and do a hard-reset? Is that part of the image documented somewhere?
We're running at 40Mhz to try and conserve battery.
Thanks,
Red
Comments
Many objects are written to work with different clock frequencies. It maybe necessary to restart them on a frequency change so they recalculate their delays and such. You will have to check the objects you want to use.
I believe the best approach in Spin is to use the methods in the Clock object to change settings since it will do the right thing about
allowing for settling times after changing PLL and OSC settings. I believe the best practice if changing PLL multiplier is switch to
RCFAST before changing PLL, then waiting an appropriate amount before switching back - until the PLL establishes lock you
have no guarantee the processor won't be overclocked and go haywire I fear.
Hmmm, that bit about switching PLL modes got me to thinking so I thought I'd try out an exercise in Tachyon as I can interactively change the clock, so I type a little code like this at the serial terminal:
4 0 DO I CLK LOOP
which just selects the PLL multipliers x1 x2 x4 and finally x8 (3 CLK) as I work with 10MHz crystals. Well that worked fine so let's really exercise it:
#100,000 FOR 4 0 DO I CLK LOOP NEXT
That took quite a few seconds but eventually came back and said "ok" so all's well.
Now I have left it on the bench with:
BEGIN 4 0 DO I CLK LOOP SPINNER ESC? UNTIL
which will repeat the CLK loop with a little spinning prompt so I know it's alive until I hit an escape key
(still running)
here will actually know I suspect. The docs are clear that merely switching the clock between stable sources is guaranteed, but I'm
not sure about whether changing the PLL divisor counts as switching between sources or reconfiguring the PLL such that it needs
to stabilise again.
Just in case I also ran a random PLL change with this bit of code:
BEGIN RND 3 AND DUP CLK 3 = IF 3 PINSET SPINNER ELSE 3 PINCLR THEN #P31 PIN@ 0= UNTIL 3 CLK
So it's a random change and the spinner will update only when it's back at normal speed and It's still running although sometimes when I run it there is a glitch. So I checked it again with a continuous switch between slowest and fastest speeds:
BEGIN 0 CLK 3 CLK SPINNER AGAIN
Which appears to run fine but I have had the very rare and occasional glitch (you only need one) too which might indicate that some caution needs to be exercised. I will try this out using RCFAST mode in-between to see if it is totally reliable.
BEGIN RND 3 AND DUP RCFAST CLK 3 = IF SPINNER THEN AGAIN