2 or more COG's running assembler
Richard Morrison
Posts: 8
I want to launch 2 COG's that each toggle different I/O pins ad infinitum at different frequencies in assembler using consecutive Spin statements
coginit(6,@routine1,var)
coginit(7,@routine2,var)
Not particularly useful (given the counters) but just want to demonstrate that it works OK (in assembler) before attempting something more interesting....
My routine1 and 2 work fine with 1 COG operating but not 2.
Can someone out there tell me how the DAT section of my program should be structured to get this to work properly ?
Thanks
coginit(6,@routine1,var)
coginit(7,@routine2,var)
Not particularly useful (given the counters) but just want to demonstrate that it works OK (in assembler) before attempting something more interesting....
My routine1 and 2 work fine with 1 COG operating but not 2.
Can someone out there tell me how the DAT section of my program should be structured to get this to work properly ?
Thanks
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
The second org is commented out at the moment.· When·this code·runs P0 has the expected square wave.
If I include the second org·only P1·appears to produce output, at a lower frequency, of course.· I am running this on a PropStick.
So how do we make both·COG's run simultaneously ?
A related·question would be - what happens if one's assembler segment needs to exceed 512 longs ??·- OK we could use a second, or third COG but how then should the DAT segment of the program be structured ?
Can't wait for the assembler manual to appear - who knows when this might be ?
I havent had a chance to get to the assembly section myself, I am still enjoying reading over the tutorial at this moment.
-JLBShecky
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-JLBShecky
Fantastic to see this made available. Thanks Parallax !! Hopefully should shed light on this issue.
-Phil
I think this is what Phil is trying to describe, only I did not seperate t1 from t2..... I tested this code, and on pin0 I read a 500kHz square and on pin1 I read a 50kHz square.
Note: You don't need the second DAT, I just did this as visual symetry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I believe your solution will work so long as cog6's code is no longer than cog7's. But if it's longer, t1 will have an address that collides with cog6's code, because it's referenced to the second org. This is one place where the "put all res statements last" rule needs to be broken. t1 belongs after data1. It won't interfere with cog7 there because cog7 will be loaded into a different cog. (Referencing addresses accross org boundaries is something the assembler ought to be flagging with a warning.)
Richard, I would encourage you to use cognew instead of coginit, BTW. Your programs will be more portable if they don't depend on which cogs actually contain your code.
-Phil
I confirmed Beau's modification works but also proved that Phil is correct too - adding just one NOP after the first XOR instruction while having both t1 and t2 in the same uninitialized data section at the very end of the program after the second org causes the high frequency square wave to get clobbered - so do separate all variables used by different COG's as Phil suggests (sounds like one for the Tricks and Traps Phil)
Thanks for the heads up on merits of COGNEW vs COGINIT too...
assembly parts with their interactions trough the PAR register.
SPIN_vs_ASM:
TwoPinsToggleWithTwoCogs.spin:
These two programs are only ment to show using cognew with parameter passing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
What God wants, God gets . . .
Her is the other one:
TwoPinsToggleWithTwoCogs.spin:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
What God wants, God gets . . .