Shop OBEX P1 Docs P2 Docs Learn Events
Why doesn't COGINIT work? — Parallax Forums

Why doesn't COGINIT work?

TheTech69TheTech69 Posts: 51
in Propeller 1
Why does the following snippet of code work but the latter does not?

cog := COGNEW(method, @stack) +1 'This works

cog := COGINIT(COGID, method, @stack) + 1 'Does NOT work

Thank you,
Jason

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    You should never use COGINIT, since you don't know which cogs are already running. Chances are good that your call to COGINIT restarted a cog that was already running and that you needed in your program. Always use COGNEW to start a new cog.

    -Phil
  • Dave HeinDave Hein Posts: 6,347
    TheTech69, the main reason that COGINIT doesn't work in your case is that you are using COGID to specify the cog. This is stopping the cog that called COGINIT, and running "method" in that cog instead. When you use COGNEW it will run "method" in a new cog that isn't currently running. If you were to use COGINIT(7, method, @stack) this would most likely work. However, as Phil said it's better to use COGNEW since you may not know if cog 7 is already running.
  • TheTech69TheTech69 Posts: 51
    Thank you for responding so quickly. The program will not even compile to allow it to run. I get an "Expected expression or term" error. Since the program won't even compile to run, I believe there are no cogs even running.
  • maccamacca Posts: 725
    TheTech69 wrote: »
    Thank you for responding so quickly. The program will not even compile to allow it to run. I get an "Expected expression or term" error. Since the program won't even compile to run, I believe there are no cogs even running.

    COGINIT doesn't return a value (see the manual), that's the error (aside from what others have said).
    In your code you are restarting the current cog pointing to 'method'.
  • TheTech69TheTech69 Posts: 51
    edited 2017-06-01 11:43
    I am using the Propeller Education Kit that came with the Propeller Manual. I also have "Programming and Customizing The Multicore Propeller Microcontroller" by Parallax, Inc. If I use COGNEW the time sensitive methods launch launch at the same time due to the parallel processing. So I need to figure out how to get the cogs to let the program know it is finished with the first method and ready to execute the next. I have not, or didn't understand something, found that in the PE Lab Manual. Any suggestions to reread in it?

    Thank you.
  • Heater.Heater. Posts: 21,230
    If you want to execute a method then, when that is finished, execute another method then why not just call them one after the other?

    That is to say, if you only want to execute methods sequentially then you do not need to start a second COG to run them. Which as you say will run them simultaneously, in parallel.

    Hmm...thinks....are your "time sensitive" methods written in PASM? That would change things a bit.
  • TheTech69TheTech69 Posts: 51
    Well I'll be darn. It turns out I didn't need to create Start and Stop methods. The preliminary code objects and method calls somewhat works. The Standard Servo Motor is moving approximately an 1/8 of a turn, counterclockwise, on its own every 2 mins. Now to research in here about that. Thank you all for your time and comments!!
  • frank freedmanfrank freedman Posts: 1,975
    Phil Pilgrim (PhiPi) wrote: »
    You should never use COGINIT, since you don't know which cogs are already running. Chances are good that your call to COGINIT restarted a cog that was already running and that you needed in your program. Always use COGNEW to start a new cog.

    -Phil

    Actually I do use the coginit to start pasm routines in specific cogs. Multiple cogs with specific functions running. Each function is assigned to a particular cog of my choosing and when the mainline runs, each cog is initialized and ready to do what it should. But I also realize that I need to allow for that in the design and make sure that calling another cog does not hammer what is already running. A project I have been working with currently uses a cog to start a timebase cog, and three ADCs all using the common timing from the time cog so that all three ADCs capture their samples at the same point in time.
  • msrobotsmsrobots Posts: 3,704
    Usually @Phil is right, using COGINIT should be avoided, except you have a good reason for.

    One reason could be that you need COG-IDs in a certain order, to use for indexing in code.

    Usually all COGs are equal, but there are some exceptions. I think @Lonesock stumbled on it first and @kuroneko verified it, that some COGs can access some Pins a little faster then other ones.

    see FSRW pasm for more info

    But if you do not NEED to, it is 'better' to use COGSTART instead.

    Enjoy!

    Mike
  • Heater.Heater. Posts: 21,230
    Of course you can use COGINIT. Why not?

    But the problem comes when you are mixing and matching Spin objects that you have not written yourself. Perhaps they come from OBEX or from a forum post or wherever. Then it's better not to have to worry about fixed assignments of code to COGs. In the same way that we use library functions in other languages and don't care what memory locations those functions end up at.

    If all of your code is under your control then do what you like.



Sign In or Register to comment.