Multiple dat sections and variables
Cncjerry
Posts: 64
If I have a number of assembler routines in one module that will each be loaded in their own cog, can each separate dat section have the same variable names? It doesn't look like it to me. For instance I have a mask for the LEDs on the QuickStart and would like to access them across three cogs by the same name. I also want each cog to have the led variable stacked the same way in the dat section at the end of the program not unlike a data block.
I thought about using separate modules but I thought I read that you can't cognew a routine from another module.
Jerry
I thought about using separate modules but I thought I read that you can't cognew a routine from another module.
Jerry
Comments
allmost right. You can't do a cognew to a routine in a module from outside.
But you can cognew that routine inside a PUB xxx in the module and call it there from outside with module.xxx ...
Enjoy!
Mike
No, it can not. All names are unique across all spin file. And it even didn't warn if you use name defined in one .dat module in another .dat module, which can cause strange and hard to find errors.
No you canot have the same labels in different DAT sections of the same object file.
Worse than that, if you have two sections of PASM in a single object that you wish to load into two cogs they cannot share a single DAT definition like a bit mask patern. It will compile but the patern will not be in the right place for one of the cogs and it will fail.
Also if you have multiple PASM for multiple cogs in a single file you will have to be sure to use org 0 at the start of each one.
All in all, I'd suggest keeping each cogs code in it's own file.
In Spin an object is a single source file. So yes the simple thing to do is have one Spin object (a source file) containing each piece of PASM you want to start in it's COG. Together with a little start method, in Spin, for it.
Usually a separate object (file) would have a "Start" method with a cognew statement. But instead of a "Start" method, you could have a method that returns the location of your PASM code to the parent object and the parent object could then use a cognew on that address. I'm having a hard time thinking of when it would be better for the parent object to start the new cog rather than just having the child object start it.
If you try to start a Spin method in a child object using cognew in the parent object, you'll get unexpected results (assuming you were expecting normal results). You should only start Spin methods from within the object(file) containing the method.
BTW, The convention is call a method "Start" if it starts a new cog. If it just sets I/O pins and some variables you're supposed to call it "Init". I'm not sure how much this convention is followed (I know I read about this convention in one of Parallax's documents about the Prop). I see a lot of "Start" methods that don't start a new cog.
org 0 cog1 mov :ptr,par rdlong :led_msk,:ptr :main_lp ... ... jmp #:main_lp :ptr res 1 :led_msk res 1 org 0 cog2 mov :ptr,par rdlong :led_msk,:ptr :main_lp ... ... jmp #:main_lp :ptr res 1 :led_msk res 1It's a big PITA to have to do it this way, but it does work. And it prevents errors due to referencing a label across cog boundaries.
-Phil
-Phil
Yes, it does default to 0.
compile error
VAR long X long Y long stack1 long stack2 Pub Start cognew(@start1, @stack1) cognew(@start2, @stack2) repeat x:=Y DAT org 0 start1 or dira, leds mov outa, leds jmp start1 leds long $0F<<16 org 0 start2 or dira, leds mov outa, leds jmp start2 leds long $f0<<16working
VAR long X long Y long stack1 long stack2 Pub Start cognew(@start1, @stack1) cognew(@start2, @stack2) repeat x:=Y DAT org 0 start1 or dira, leds mov outa, leds jmp start1 leds long $0F<<16 org 0 start2 or dira, leds2 mov outa, leds2 jmp start2 leds2 long $f0<<16I overlooked the colon ":" in Phi's example above and was on the org 0 method.
What does the colon in a label prefix mean?
As for the colon thing, Imagine your PASM was split into two or more funtions that get called from some other main function. All those functions would need some normal label.
But perhaps they all have some local place to jump to internaly and you might want to give those places a generic label like "loop". Well normally you would have to label them as "loop1", "loop2" etc. But in PASM you can call them all ":loop" and there will be no conflict. They are local to the function.
You can think of regular, non-colon labels as "fences" that enclose areas of colon labels.The colon labels are known within their own fenced-in area, but not outside of it. Therefore you can reuse them with impunity between multiple fenced-in areas.
BTW, this statement in my example above may actually produce an error:
Being "on the fence", it can "see" both the :ptr label above it and the one below it. You may need to add an extra fence above the entry point or add a statement before the mov.
-Phil
-Phil
Also, per my other thread and helped by Heater, it looks like one of my main problem with consistency was brought about by not prefacing my jumps with the # for literals. Surprised it worked at all. Really strange errors.
One other question on that note. In my start1 and start2 functions above, is there a way to "phase" the second function so that they become more clock synchronized? So let's say I have a start1 cog that sets a bit, and a start2 cog that clears a bit and I wanted them to be phased so that the start1 sets the bit on one clock cycle and the start2 clears it on the next. Not sure where I would use this, more of an academic issue but curious.
Thanks for all the help. This is a great forum.
Jerry
-Phil