View Full Version : PHSA/PHSB access from Spin

Phil Pilgrim (PhiPi)
01-08-2008, 11:52 AM
Here's a program whose behavior perplexes me:


_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

freq = 10000
advance = 6000
pina = 14
pinb = 15

PUB start

frqa := ((freq << 16) / clkfreq) << 16
ctra := constant(%00100 << 26) | pina

frqb := ((freq << 16) / clkfreq) << 16
ctrb := constant(%00100 << 26) | pinb

phsb += advance
waitcnt(cnt + clkfreq * 2)

It starts two NCO clocks, both with the same frequency, with outputs on pins 14 and 15. In the repeat loop, phsb gets incremented by advance. But here's the weird thing: The amount by which the phase of pin 15, relative to that of pin 14, advances at each step (as seen on a scope) is independent of the value of advance, and equals about -3.7s. What's up with that? Is Spin doing a read-modify-write on phsb, thereby reading phsb's shadow register? Well, I tested that theory by doing an explicit read, followed by a modify, then a write. 'Same results, with just a longer phase shift.


Post Edited (Phil Pilgrim (PhiPi)) : 1/8/2008 5:05:39 AM GMT

01-08-2008, 12:31 PM
Hi Phil
have you tried
ctrb:= (constant (%00100 << 26)) | pinb


ctrb := %00100<< 26 | pinb

just some guesses that I would try..

ron Mel oz

Post Edited (OzStamp) : 1/8/2008 5:36:38 AM GMT

Phil Pilgrim (PhiPi)
01-08-2008, 12:55 PM
No, the counter configurations are okay, and they're outputting at the expected frequency. It's just the ability to adjust their relative phase on the fly, after configuration, that's got me bamboozled.


Tracy Allen
01-08-2008, 02:57 PM
Phil, was that indeed a phase retardation of -3.7 s instead of advance?. hmmm

The value, advance=6000 is practically nothing in terms of phase, because phsb would be advancing by 524_288 (=2^19) every 12.5 ns. It should take a value of advance=155_189_248 to evoke a 3.7 s phase advance. That is about 1/28 of the full cycle. Did you try numbers up in that range or higher, and still the same result?

Tracy Allen
www.emesystems.com (http://www.emesystems.com)

01-08-2008, 03:01 PM
It doesn't have to do with the spin execution timing does it?


Phil Pilgrim (PhiPi)
01-08-2008, 03:35 PM

A phase retardation of x is just a phase advance of period - x, so that doesn't bother me, since I assume there's some Spin overhead that also gets added in.

I did try some numbers orders of magnitude bigger than 6000, but you're right: they weren't nearly big enough to make a noticeable difference. Now that I've tried some really, really big numbers, I'm seeing some effective differences. Thanks for making me revisit my assumptions! http://forums.parallax.com/images/smilies/smile.gif


01-08-2008, 04:25 PM
The 3,7s is exactly the time it takes SPIN between READING the PHS and RESTORING it (with practically the same value , as Tracy rightly remarked) http://forums.parallax.com/images/smilies/smile.gif

So you practically discard all the hardware induced PHS increments during that time, giving you the observed retardation. When beeing morte explicite that
PHSA += advance
this retardation will increase of course, as you already noticed.