Interaction between cogs?
port513
Posts: 50
First of all, I'm new to this!
Is there a way to have cog1 to read temperatures etc and then pass this information to cog2 without using a public variable etc?
/Henke
Is there a way to have cog1 to read temperatures etc and then pass this information to cog2 without using a public variable etc?
/Henke
Comments
Long: there is no communication other than shared memory (HUB memory) between the cogs. You may use some external device (memory) that both can use... but it may be too complicated. A shared portion of HUB ram can be easily used for both cogs using the PAR register to pass the address. Simple semaphores can be implemented using the lock instructions... but variables... no.
I thought for a project that would read an external memory that 4 cogs read simultaneously and process the data the 4 of them at the same time. That way the work could be balanced (shared for better use of cog ram).
May be a tad faster than using hub RAM in some circumstances for example just setting a synchronization flag. Wastes pins of course.
One could set up a "covert" serial channel by setting and unsetting a lock with with some clever timing (or use multiple locks for parallel) but that would be just weird.
Weirder still: You could modulate data on to the system clock mode using CLKSET.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
That question has come up before, as far as I remember Port B is not wired. So no joy there. Can't find the thread about it just now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
However I still think it might be worth it just to avoid using HUB RAM and all that dicking around with pointers, semaphores and locks etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A cog can access the hub every 16 clocks, and at that time transfer a long word (32 bits).
So if you have a clock of 80MHz, then the transfer rate is 80 MHz / 16 x 32 bits per second = 160 M bits per second. Note that this is the transfer rate per cog. The gross inter-cog transfer rate is x 8 = 1.28 G bits per second.
The fastest demonstrated serial comms between cogs is burst rates of 8 M bits per second over a single wire connection. So you would need 20 pins connecting 2 cogs to even get close to the speed of optimised hub transfers, and that is only for one way communication between 2 cogs.
Although this question raises its head from time to time, my personal belief is that it is of academic interest only. Just use shared hub memory locations. They really are quite fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Yes and NO.
It is not alwais speed that is important. But fuly important is Prop to Prop comunication with few pins (1 clock and 1-2 in/out.
That comunication has many use with 2 and more Props. Comunication COG to COG with that construction reached automaticaly
and only programers programing skill can utillize that capablity.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://forums.parallax.com/showthread.php?p=650217
meow, i have my own topic now? (sorta)
As I know all 64 Pins will be accessible outside Prop II
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
There are simple mechanisms to pass data between cogs via hub (see FullDuplexSerial even though it is spin passing, PASM could be used). Mostly, because of determinism, locks are not required. The only thing that may be requires is a fast synching mechanism, and that can be done by wasting a pin (sitting on waitpeq). Alternately, set the cnt parameter in hub and synchronise to that. This is what I did in my DataLogger - uses 4 cogs interleaved to sample all 32 pins at 12.5nS (about 480*4 samples, but could have used 8 cogs for 480*8 samples). The Prop II will be twice as fast.
Yes I agree, most of the time. Consider what happens now when all your cogs are in use but you want to add a few more processes, device drivers, whatever. Easy, add a second Prop to your design. But then you have to create some inter Prop communications in hardware and software. Then you have to modify some of you objects to communicate through that new "channel" from Prop to Prop. Any existing obects from obex or wherever would need serious changes to move from using HUB ram to the whatever new channel mechanism you have come up with.
Now, IF that concept of a "channel" were built into the Spin language one would only have to make a small change somewhere to the definition of "channel" to change from COG to Prop to Prop link. Objects using this mechanism could be easily migrated from Prop to Prop.
The physical reality of "channel" could well be through HUB RAM in a single Prop case but would automatically use Prop to Prop links when configured to do so.
As it stands we don't care (or know) which COG a process runs on when we write an object. With a "channel" mechanism we would similarly not neeed to know which Prop the processes run on.
Given the wonderful idea we have now of COGs as general purpose "devices" it would be great to extend that idea out of a the bounds of a single Prop.
Serial links between Props could be very fast using video shifter like hardware.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Agreed, and it doesn't really matter how it's implemented as long as it's there.
A Cog ( or code it is interpreting ) shouldn't care if it's talking to another Cog/Program on the same chip or on a different one, or even via another Cog, over the internet, and through another Cog on a different system on the other side of the world.
This isn't so much bottle-neck solving nor speed improvement but transparent comms.