the coginit-command problem

Comments

• Duane Degn Posts: 10,588

  2014-05-27 11:36 edited 2014-05-27 11:36

  I see a couple of problems. The main problem is you're only use one long as the stack. Add a "[64]" (or other appropriate stack size) after both stack declarations.
  

  VAR
    long  ID
    long  JC
    long  JD  
    long  Stack[64]
    long  Stack1[64]
    byte  Cog
    byte  Cog1
    long  Time, Counter1, Last1, Delta1, Counter2, Last2, Delta2, Total2
    byte  Success
  

  
  It's also very dangerous to use coginit. cognew is generally the preferred way of starting a cog.
  
  Another issue is you just let cog #0 die. Why not use it for one of your tasks instead of starting a new cog?
  
  Instead of starting the method "encoder" in a new cog, your "main" method could just call "encoder" and have the method run in cog #0.
  
  I'm confused how you're using the encoders. It doesn't look like the object "Encoders" is ever used.
• hcchen Posts: 14

  2014-05-27 12:56 edited 2014-05-27 12:56

  After transforming the both stack declarations and "coginit". The both functions can work fine. Thank you for your correction
  
  I neglect the cog#0.:thumb:(carelessness)
  I don't know how to use "Ecoders".(Forget to remove the object)
  I try to write the encoder which can read pulse on pin2.
  if my code can't be use, I will find the information about "Encoders".
• Duane Degn Posts: 10,588

  2014-05-27 13:50 edited 2014-05-27 13:50

  I've posted some encoder code here. IIRC, the code in post #2 doesn't use PWM and is encoder only. One of the version includes a speed calculation.
• hcchen Posts: 14

  2014-05-28 21:35 edited 2014-05-28 21:35

  thank you.
  I will try to understand the code how to work.
• Alexander (Sandy) Hapgood Posts: 360

  2014-05-29 16:02 edited 2014-05-29 16:02

  Duane Degn wrote: »

  It's also very dangerous to use coginit. cognew is generally the preferred way of starting a cog.

  
  Sorry but I take exception to this statement every time I see it. Coginit isn't inherently dangerous but, like every other command in every other language, you have to have a certain amount of knowledge before you can use it effectively. It, like some other commands, may not be suitable for people with little programming experience.
  
  Knowing how to use coginit properly will allow you to change the code a cog is running during program execution or run PASM in all 8 cogs.
  
  Basically it comes down to managing an array of 8 variables.
  
  Sandy
• Phil Pilgrim (PhiPi) Posts: 23,514

  2014-05-29 16:30 edited 2014-05-29 16:30

  Alexander (Sandy) Hopgood wrote:

  Sorry but I take exception to this statement every time I see it. Coginit isn't inherently dangerous ...

  Sorry, but I take exception to your taking exception. Most objects that start new cogs use cognew, so there's no legitimate way to know a priori which cogs are available to use with coginit, once these objects have started.
  

  Knowing how to use coginit properly will allow you to change the code a cog is running during program execution or run PASM in all 8 cogs.

  
  True: those are both legitimate uses of coginit, but only to the extent required for reloading the cog you're running in with new code. In virtually every other case, it's unnecessary to assign code to any particular cog. Especially for just starting a new cog, cognew is still the best way to go.
  
  -Phil
• Alexander (Sandy) Hapgood Posts: 360

  2014-05-29 17:25 edited 2014-05-29 17:25

  You have a point. Coginit isn't always the best choice but neither is cognew.
  
  A good mechanic will know the capabilities of every tool in his toolbox and know which is the appropriate tool for the job. That way you get to use all the tools.
  
  
  Most infantrymen believe that a piece of high explosive will solve any problem. One tool for everything!
  
  Sandy