Passing data between cogs in Tachyon
artkennedy
Posts: 174
in Propeller 1
Compadres, I am struggling with understanding how to pass numeric values from one cog to another.
I find the descriptions of the revelant words in the Glossary and Introduction to be confusing.
For instance I want to make a cog clock a port at regular intervals that can be changed from my
main program. Any help?
I find the descriptions of the revelant words in the Glossary and Introduction to be confusing.
For instance I want to make a cog clock a port at regular intervals that can be changed from my
main program. Any help?
Comments
Just use a variable that any cog can read and write to.
Wow, I tried doing it with constants and that didn't seem to work. Missed the obvious. I was trying to use the ATN/ENQ words. Thanks.
Also a task that has been stopped still appears in the .TASKS list. Is that expected?
When I stop a task with n STOP does appear to stop but is still listed.
Generally once a task is started, it is rarely stopped although you can simply exit and return control to the IDLE task which ran it for you in the first place.
If you do a COGSTOP it destroys this whole IDLE mechanism so you should build something into your code to ask it to exit back to IDLE.
There's only so much we can do with cogs and unfortunately there isn't any kind of ability in the P1 other than to init it, or stop it.
Here's the code for the IDLE loop which all the unused cogs are running after having been coginit'd with the Tachyon kernel at boot. Remember, you have to have a binary image present in hub memory to coginit it into the cog.
btw, the 8 ms in the idle loop was inserted at a time when I needed my P1 to draw 20ma or less since it was built into and powered from a Maxon motor control module.
Funny, seems when I give up and ask for help I work on it a little longer and find a solution.
I'm using BEGIN ..... ATN@ UNTIL in the cog
and stop it with ' NOP cogn ATN!
Works just fine but I still don't know why cogn STOP does not.
If you simply pasted the code in you should notice that it wasn't happy with STOP and prints out the ??? response.
If you used the block mode TACHYON & END then after END it will issue a compile report and let you know that it found errors.
I should have mentioned that I am using version 2.7. Maybe I should catch up.
This is from the EXTEND for 2.7:
{ This is actually handled by STOP
\ 03 0C 7C 0C | cogstop 6
pub COGSTOP ( cog -- \ stop the COG with number cog 0..7 )
9 SHL %000011_0001_1111_000000000_000000011 OR PASM DROP
;
}
I don't even maintain a dedicated folder for anything before V3!!! Looks like 2.7 came out 4 years ago, that's forever ago in the lifetime of a Tachyon
The early versions stilled used bytecode and from V4 it streamlined to wordcode which actually uses less memory in real applications and runs faster etc. V5 has been out for quite a while now and the kernel itself allows ROMS to be added to the upper EEPROM over the serial port. V5 also has a much faster dictionary search so that you can reduce the terminal line delay to almost zero.
Here's the kernel source or you can load the complete binary instead.
I edited TACHYON5v7.spin to change the baud rate to 230400. Loaded with the Prop Tool. Instead of the 'Ok' prompt there was "...". Is that as should be? Then I pasted from EXTENDv5.FTH and got a big jumble of words and ??? etc. I'm using TerraTerm. More help?
Here is a line from my terminal: Note that I also changed my --> to a --- as this is also the same as a comment.
As for EXTEND.FTH you should make sure that TeraTerm has its line delay set to a few milliseconds when pasting.
In fact I just tried using Prop Tool on Windows to load the kernel and start it up, and then used TeraTerm with a line delay of 1ms (no handshake), and it complied perfectly. Before these recent improvements to Tachyon's compile speed, the line delay had to be set to a minimum of 8ms and usually 12ms.
Note that if you have any ROMs loaded into upper EEPROM then they will still be there even after loading the kernel, since this only affects the lower 32k.
BTW, The kernel is designed so that you don't need to change the baud rate there, except in special circumstances, but rather just change it at runtime using CONBAUD.
Antelopes are skeptical of changes in their cages. - Paul Simon
Why all those 00's between the address for 'code' and the data?
... TABLE codes 160 ALLOT --> ok
... $00FB || $A66C || $00FB || $A664 ||
... $00FB || $A66A || $00FB || $A662 ||
... $00FB || $A669 || $00FB || $A661 ||
... $00FB || $A66D || $00FB || $A665 ||
... $00FB || $A66B || $00FB || $A663 ||
... $0045 || $1533 || $0045 || $153C ||
... $0045 || $15C3 || $0045 || $15CC ||
... $0045 || $1703 || $0045 || $170C ||
... $0045 || $1D03 || $0045 || $1D0C ||
... $0045 || $1503 || $0045 || $150C ||
... $0001 || $153C || $0001 || $153C ||
... $0001 || $150C || $0001 || $150C ||
... $0001 || $150F || $0001 || $150F ||
... $0001 || $1530 || $0001 || $1530 ||
... $0001 || $1533 || $0001 || $1533 ||
... $0001 || $153C || $0001 || $153C ||
... $00C5 || $1761 || $00C5 || $1761 ||
... $00C5 || $1762 || $00C5 || $1762 ||
... $00C5 || $1764 || $00C5 || $1764 ||
... $00C5 || $1768 || $00C5 || $1768 ||
... ' codes 384 DUMP -->
0000.3C88: A0 80 7C 06 5A 00 5A 00 01 7D D4 00 5A 00 5A 00
0000.3C98: 5A 00 5A 00 00 00 00 00 00 00 00 00 00 00 00 00
0000.3CA8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000.3CB8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000.3CC8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000.3CD8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000.3CE8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000.3CF8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000.3D08: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000.3D18: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000.3D28: FB 00 6C A6 FB 00 64 A6 FB 00 6A A6 FB 00 62 A6
0000.3D38: FB 00 69 A6 FB 00 61 A6 FB 00 6D A6 FB 00 65 A6
0000.3D48: FB 00 6B A6 FB 00 63 A6 45 00 33 15 45 00 3C 15
0000.3D58: 45 00 C3 15 45 00 CC 15 45 00 03 17 45 00 0C 17
0000.3D68: 45 00 03 1D 45 00 0C 1D 45 00 03 15 45 00 0C 15
0000.3D78: 01 00 3C 15 01 00 3C 15 01 00 0C 15 01 00 0C 15
0000.3D88: 01 00 0F 15 01 00 0F 15 01 00 30 15 01 00 30 15
0000.3D98: 01 00 33 15 01 00 33 15 01 00 3C 15 01 00 3C 15
0000.3DA8: C5 00 61 17 C5 00 61 17 C5 00 62 17 C5 00 62 17
0000.3DB8: C5 00 64 17 C5 00 64 17 C5 00 68 17 C5 00 68 17
0000.3DC8: 00 80 86 3C 80 81 44 0B 5A 00 5A 00 00 00 00 00
0000.3DD8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000.3DE8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000.3DF8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
you told it so
you do not have to do the ALLOT here.
What it does is just allot 160 bytes which are mostly $00 and then compile the data.
Actually the first few bytes is 'garbage' from the compilation process, which will be overwritten by ||
if you omit the ALLOT.
so just remove the 160 ALLOT and you are fine.
You do not have to specify the size.
|| compiles words one after the other.
That is what I was using in 2v7 and it worked fine. I tried it in 5v7 and it was funky. I tried using 160 ALLOT to fix the probs. Now it's good. Maybe something was corrupt at the time. Thanks again.