simple use of cognew
mikediv
Posts: 825
Guys can you take a look at this code I have been trying to learn how to use multiple cogs for running programs at the same time what I want to accomplish is having the ability to run very simple code to just demo blinking or turning on an LED I can do that running the demos
but I am having a hard time grasping how to implement the cognew command with my own simple commands.
So say I just wanted to turn on an LED on pin 19 cognew"something dira[noparse][[/noparse]19]:= 1 outa[noparse][[/noparse]19]:= 1 , @ stack[noparse][[/noparse]30]) ?????
The attached rpogram works fine with the exception of the line I commented showing how I tried to load a new cog with the dira registry if anoyne can take a look I would appreciate it I do not even want to mess around with with timing just turn on or off an led and read an input from a few differant cogs thanks
but I am having a hard time grasping how to implement the cognew command with my own simple commands.
So say I just wanted to turn on an LED on pin 19 cognew"something dira[noparse][[/noparse]19]:= 1 outa[noparse][[/noparse]19]:= 1 , @ stack[noparse][[/noparse]30]) ?????
The attached rpogram works fine with the exception of the line I commented showing how I tried to load a new cog with the dira registry if anoyne can take a look I would appreciate it I do not even want to mess around with with timing just turn on or off an led and read an input from a few differant cogs thanks
spin
588B
Comments
The line that isn't working does not call a valid subroutine like the three following it.
Also, just a note about your stack space. I can see how your calling the routine without crossing up each cogs stack space with another, but when your code grows it is going to get nightmarish to keep the stack alined for each cogs demands. It would be better to declare different stack arrays for each cog or purpose you intend to use. This habit might save you some grief latter
You can't put real code inside of a cognew, only a function call or a PASM-adress is allowed here if you want it to work properly.
BUT : even if you would write a function for these 2 lines of code you'd hardly see anything! Problem is that without a loop the COG will be finished doing the work before you can see the the LED at all. Remember: each COG has it's own copy of DIRA and OUTA registers, which will be out of function when the COG is not running.
@stack[noparse][[/noparse] 30 ] points to some memory that no longer belongs to the array, as the array ends at stack[noparse][[/noparse] 29 ] .... And even that would not work properly, as the cognew itself needs some space on the stack. 1 long would not be feasible.
bambino already mentioned it, having several stack arrays is a good idea, as you can increase each single stack in case one COG runs out of stack-space without the need to touch any other cognew. If you don't expect a RAM shortage for your program you should be a bit more wasteful with stack-space, as stack-overflow bugs can do really funny things.
the whole cognew stack concept. So when you say my index range for stack[noparse][[/noparse]30] is 0-29 are you refering to a memory space/segment?
Like I posted above I can use multiple stacks using the parallax sample programs but my problem is when are tried to send my own program to a cog
I did not realize I could not use "real code" I thoguht I could put a few small spin programs that did somehting light an LED poll a switch to a few cogs at the same time.
I guess to put this simply ""cognew(blink(16, clkfreq/3, 9),· @stack[noparse][[/noparse]0])""" is valid code and works I know blink is what to do clkfreq/3 is just that and 9 is how many times to blink the led so is this what to do to send multiple programs to cogs is this the only format to use??? I know I am missing something simple
about the concept that why I though I would start small and just blink leds , the Parallax samples work but they all just use this format I Was hoping there is another way Thaks again everyone
·
Each variable defined in a function and not in VAR or DAT section is created on the stack.
As each COG runs it's own program and the programs run independently, each COG needs it's own stack space. How much stack one program needs depends on the number of nested function calls and the number of local variables each function needs.
Of course you can have one array and split this up for each cognew, say stack[noparse][[/noparse] 0 ]-stack[noparse][[/noparse]·9 ] for COG1 and stack[noparse][[/noparse] 10 ]-stack[noparse][[/noparse] 19 ] for COG 2 and so on. That's what you already do in your program. In your COGNEW you give each COG a different stack-start-adress.
The number in the square brackets is called index.
stack[noparse][[/noparse] 5 ] accesses array element with index 5. But as the index starts with 0 the maximum index of an array of size 30 is 29. So, in your program you pass @stack[noparse][[/noparse] 30 ] which is an adress that no longer is inside of your array. I'm not sure what happens .. I guess the stack space of COG 0 will be overwritten, as COG 0 (which runs the initial code) uses all not used RAM as stack space, starting directly behind the last long used by the program.
So ... most important lesson to learn: If your stack-space is smaller than the space a program needs, everything can happen - you overwrite code or data or stack space of other COGs. To be on the safe side, you should make the stack big enough, so that you don't have to increase it after adding a·locale variable to a function.
And if you have a look at your code ... if you want to increase the stack for the first COGNEW (the one that works having @stack[noparse][[/noparse] 0 ]) you have to change the code for all the following COGNEW as well. So, it's better to have a stack per COG.
In this case, whenever you figure out that a stack runs short, you only have to increase the size of that stack.
The 2 possibilities you have for COGNEW are:
1. cognew( spinfunction, @stack )
2. cognew( @pasmcode, parameter )
You can not replace spinfunction by a spin instruction!
You can call any kind of spin-function, which means it can have any number of parameters - as you can see in the above code example. function1 has 2 parameters, whereas function2 has only one. And ... as you did in your code, you can start one function several times in different COGs ... but each has to use it's own stack.
·