PHSA/PHSB access from Spin

Phil Pilgrim (PhiPi)

Here's a program whose behavior perplexes me:

[b]CON[/b]

  [b]_clkmode[/b] = [b]xtal[/b]1 + [b]pll[/b]16x
  [b]_xinfreq[/b] = 5_000_000

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

[b]PUB[/b] start

  [b]frqa[/b] := ((freq << 16) / clkfreq) << 16
  [b]ctra[/b] := constant(%00100 << 26) | pina
  [b]dira[/b][noparse][[/noparse]pina]~~
  
  [b]frqb[/b] := ((freq << 16) / clkfreq) << 16
  [b]ctrb[/b] := constant(%00100 << 26) | pinb
  [b]dira[/b][noparse][[/noparse]pinb]~~
  
  [b]repeat[/b]
    [b]phsb[/b] += advance
    [b]waitcnt[/b]([b]cnt[/b] + 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.7µs. 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.

-Phil

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

OzStamp

Hi Phil
have you tried
ctrb:= (constant (%00100 << 26)) | pinb

or····

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)

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.

-Phil

Tracy Allen

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

stevenmess2004

It doesn't have to do with the spin execution timing does it?

Steven

Phil Pilgrim (PhiPi)

Tracy,

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!

-Phil

deSilva

The 3,7µs is exactly the time it takes SPIN between READING the PHS and RESTORING it (with practically the same value , as Tracy rightly remarked)

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.