SPIN to ASSY flag and variable transfer

parsko

Hi guys,

Simply said, I need to send a flag from SPIN to start an ASSY (separate COG) loop. (It's a one time ADC capture, on demand)

The ASSY routine needs to loop until the flag says it should start.

I tried Mikes method as mentioned here:

Mike Green said...

If you want to have these routines in separate objects, add a set_flag and get_flag method to the get_value object

PUB ChangeControl( ... )
  ADC.set_flag(1)  ' release the ADC cog to get a value
  ...
  repeat while ADC.get_flag == 1 ' wait for the ADC cog to finish

ADC object

VAR byte flag
PUB get_flag
  return flag
PUB set_flag(f)
  flag := f
PRI get_value( ... ) ' independent cog to read ADC
  repeat
    repeat until flag == 1 ' wait for a request to read ADC
    ...
    flag := 0 ' signal that we're done

...but it doesn't seem to work for an ASSY routine in another cog.

Anyone have another suggestion for how to do this? Did I miss something obvious? I have been staring at this for a bit...

I think it can be done using a spare pin and WAITPNE, and not worry about cross-cog clobbering of variables. I have a feeling that it might be the variable read/write to main memory, although you should be able to do it for one address without an issue.

Thanks,

-Parsko

Mike Green

At the end of the assembly routine, I think the two returned values are reversed from what you expect. You're storing the ADC value in the first long and the flag value is stored in the second long.

parsko

Mike,
I'm not sure that that is it.· My posted code, unfortunately, was not working when I compiled it (but I was tired and wanted to get this out) so the code might not be perfect.· But, what you see is the culmination of many hours of testing.· BUT, with that said, it shouldn't matter, cause in my main loop, I output these numbers to the TV, and if they were backwards, I'm not sure it would care.

I think my issue is that I keep "polling" the Flag from the assy code, but never give enough time for the same variable to update from the spin code, or visa-versa.· Hence my cross-COG clobbering.

I know that I am able to write to the 2nd value in the array by using "tempaddr" and add tempaddr, #4.· I have tried this and know it works.· Everything seems to fall apart when I use the other value in the array, either read or write.·

This had lead me to believe that I can't do flags from SPIN to ASSY if other values are being updated to (my ADCvalue).
I am also worried about actual value of polled variable.· When I:

LINE 1mov     tempaddr, PAR
add     tempaddr, #4
mov     _ADCvalue_1, tempaddr

The code above moves the actual value of what is stored into _ADCvalue_1, from tempaddr, correct?· I have a funny feeling that it only stores the address itself.

I have become very confused by all this.· Is what I am trying to do possible?· If so, does anyone have a working example?· Or, can anyone verify that my concept/technique is known to work?

Keep in mind that I am transferring an array of two variables to the ASSY cog, and trying update/modify both (technically, only modify(two way)·the flag, and update(one way)·the ADCvalue)

Eventually, I plan on stringing two or more assy routines into this same routine.· This would allow me to set a flag,·have multiple high-speed ADC's running in sequence, then return the values and clear the flag.

-Parsko

Post Edited (parsko) : 10/3/2006 7:14:18 AM GMT

Mike Green

1) In the snippet you posted, the last line is a "mov". You probably meant "wrlong".

2) I use this technique all the time and a number of the I/O drivers that Parallax has developed use this technique (passing the address of a block of data to an assembly routine with the assembly routine communicating with SPIN routines through changes in the block of data).

3) The keyboard driver is a straightforward example of this. It does some work in the assembly routine that ends up producing data that gets put into a buffer. SPIN routines read the data out of the buffer.

4) It shouldn't matter how often you poll the flag from assembly code. The flag should always be the last thing set and the first thing tested because a change in the flag value implies that everything else has already been set up and that the cog setting the flag isn't going to do anything else with the data until the flag gets cleared. It's kinda like a "here it is" signal from one to another, then an "ok, back to you" signal. Note that this only works with two cogs communicating back and forth. If you have 3 or more cogs talking, you will need to use semaphores (locks).

parsko

Thanks for the response. I am also guessing that it might have something to do with the timing of the ADC capture. Tonight, I'll strip it down to a more simple procedure (aka take out the ADC and instead use a blinker) to see if I can get the transfer to work correctly.

Thanks for the response. You confirmed that it should work, which is the most important advice to me right now.

Funny, as a tangent, I'm in Holland (expat), and work normal work hours (9-5). I know when the people on this forum are sleeping. Around 9-10 until around 3-4 this forum is DEAD quiet (I get email alerts to my work email, so I'm aware). About this time of day, people wake up on, go to work, respond to posts, etc...

So, for those of you who fall into this category, good morning, get some coffee, and figure out why none of us can write perfect code!!! [noparse]:)[/noparse]

-Luke

parsko

Found it. Ended up being a missing "#" in a jmp loop address. Knowing this, my code has probably worked for about 4 revisions. Now my little 2" LCD is zipping away...

Thanks again,

-Parsko

PS- See working code attached...

Paul Baker

Glad to see you got it working Parkso, the # is one of those little gotchas you have to watch out for when programming in assembly. Almost always you will use a # before the address in a jump, the only exception is when you are doing an indirect jump.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

parsko

Thanks Paul.

It occured to me, since this is somewhat of an abstract concept, that I might put together a bare-bones two-object project for the ASSY sticky. It would be nice for others to find this easily. I must have spent 10-15 hours on this only to realize it was that stinkin' little # symbol. But the variable transfer between stuff has been one of the topics I have spent the most time learning on the Prop thus far. That and the counters (which I'm still workin on).

-Parsko

PS- It cracks me up to see how often people type "parkso" instead of "parsko". I bet you didn't realize it. BTW, Paul, are you coriolis, Paul Baker, or both?

Paul Baker

Sorry I messed up your name. Coriolis is my login name, Paul Baker is my real name. Im from Florida originally, so Ive used coriolis as a sig for years, since it is what determines the rotation of hurricanes.

I am returning to the counter docs today, Im hoping to get it out before another high priority item comes along.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Jamesx

Parsko:

I would encourage you to add useful and/or insightful code to the Assembly sticky thread. There is very little on assembly programming in the manual, and not many threads on this forum about how to do simple coding. The sticky thread is excellent, though, and I've spent hours and hours over the last few days studying it and modifying the code presented there.

With the help of this thread, today I reached a milestone. I fired up an ADC-831 (from an old Stamp kit) and got it really screaming. An assembly cog passing data to a spin cog which then sends it out at 230K baud with the full duplex object. Nice!

(What really stumped me was that the clocks and loops were way too fast for the ADC-831. Sometimes going really fast is not good.)

I'll check out your file and see how you did the transfer part.

Thanks,

Jim C.