*Solved*: Is an assignment (SomeVar:= someValue) atomic? It *IS*

Nick Mueller

Hi!

[noparse][[/noparse]Edit]
Have written a test program. One Updater in SPIN, and an Observer in ASM. And I cant observe what I suspected.
So the error is somewhere else (despite having chased it for a day).
I leave my the question JFTR
[noparse][[/noparse]/Edit]

Admittedly, this question sounds *quite* strange. But I'll describe the problem:

I have one cog running some SPIN-code that is updating a global var (I call it triggerPattern). This global var is repeatedly fetched from ASM (via rdlong) and used for generating some timed pulses on a pin.
Now if I let repeatedly update the var "triggerPattern" from SPIN, I do have jitter on the output. If I remove the update and only write the var once with some value, the jitter is gone. Ah!, you'll say, the value you write isn't constant. It is, I changed the code to repeatedly write the *same* value.

Now does that make sense?
I'd expect that a

triggerPattern:= someLocalVar

does do a wrlong deep down inside the SPIN interpreter. Without any side-effects.

If that makes a difference, "triggerPattern" is in fact an array.


Any insights?
Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Post Edited (Nick Mueller) : 12/8/2007 4:07:41 PM GMT

deSilva

For debugging I would let the second COG check what values are read in the first place. Say you expect 999 as the constant value, a deviation can be reported.
You might learn something from that value... It will be most likely "zero"..

The internal working of the SPIN interpreter is still a secret

hippy

Perhaps the Spin interpreter writes to a long variable in hub not using wrlong but using four wrbyte ? If using wrbyte, going from $FFFF_FFFF to $0000_0000 would see the value pass through $FFFF_FF00, $FFFF_0000, $FF00_0000 ( or similar ). Depending upon when the reading cog pulled in the hub variable value it could be any of those.

However, if you are always writing the same value in the Spin code, unless the hub variable is being cleared by the Spin interpreter before the value required is written it should never change at all.

If the Spin interpreter updates using wrlong and doesn't alter the variable before (re)writing the required value, I'm at a loss to explain the jitter.

You could add a lock around the spin code and your rdlong so the variable is never read while being updated by the spin interpreter. That would help identify whether it was an interaction with the way the interpreter operates or some other issue.

Nick Mueller

> However, if you are always writing the same value in the Spin code, unless the hub variable is being cleared by the Spin
> interpreter before the value required is written it should never change at all.

That's exactly what makes me wonder the most.


> You could add a lock around the spin code and your rdlong so the variable is never read while being updated by the spin interpreter. > That would help identify whether it was an interaction with the way the interpreter operates or some other issue.

No time for reading/writing a lock.
I have packed the information that needs to be in-sync/atomic into a single long.

I'll write a testprogram to verify what I can't believe.

Anyhow, the SPIN-code that is updating the global value has to be reqritten in ASM (does it now for testing) and then I won't no longer have that problem. I just stumbled over the problem when I saw the jitter and had no explanation for it.

I'll keep you updated.
Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

hippy

It's worth adding the lock at least temporarily to see if the problem goes away or not, or create some other test program as you suggest to try and identify what the cause or symptoms of the failure are.

Mike Green

If what you describe is indeed what you have done, then the jitter doesn't make sense because I'm sure Spin does a WRLONG to store into the LONG variable. In other words:

You have one cog running Spin that does a "triggerPattern := localVariable". You have another cog running an assembly program that does a RDLONG on the location of triggerPattern. You've setup localVariable so it is a constant value. You see jitter on your signal that implies that there's a timing interaction between the cogs, that somehow triggerPattern changes briefly from what's expected.

The above can't happen as described. WRLONG is indeed atomic, accomplished indivisibly during one hub cycle, and, other than changing the contents of that long, does not affect other cogs. There must be something else going on in your code and we can't tell without the source code to look at.

Nick Mueller

OK,
thanks guys for your time I wasted with my question.
An assignment to long in SPIN *is* atomic (see my edit of the original post).

Albeit, no explanation of my problem. But you can't help me there.


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO