cognew is NOT!

RS_Jim · 2013-02-16 06:26

Ok, so I have an object that calls another and the both function correctly. When I put the second in a new cog it doesent. The hardware is a Demo board'. Leds are to trace where the code gets to. So where does the train come off the track?

CON

  _clkmode      = xtal1 + pll16x                        ' use crystal x 16
  _xinfreq      = 5_000_000
  
  CS = 16  ''CS: Clear Screen      
  CE = 11  ''CE: Clear to End of line     
  CB = 12  ''CB: Clear lines Below 

  HM =  1  ''HM: HoMe cursor       
  PC =  2  ''PC: Position Cursor in x,y          
  PX = 14  ''PX: Position cursor in X         
  PY = 15  ''PY: Position cursor in Y         

  NL = 13  ''NL: New Line        
  LF = 10  ''LF: Line Feed       
  ML =  3  ''ML: Move cursor Left          
  MR =  4  ''MR: Move cursor Right         
  MU =  5  ''MU: Move cursor Up          
  MD =  6  ''MD: Move cursor Down
  TB =  9  ''TB: TaB          
  BS =  8  ''BS: BackSpace          
           
  BP =  7  ''BP: BeeP speaker          
  rainpin = 7
Var
  long Stack1[50]
OBJ

  debug : "Parallax Serial Terminal"
  rain  : "raingage021513a"
  delay : "timing"
  num   : "simple_numbers"
  

Pub Main | tmp            
  debug.start(115200)
  'cognew (testpulse,@stack1)
  tmp:=rain.Start(rainpin)  
  ifnot  tmp >0
    debug.char(NL)
    debug.str(string("oops"))
  debug.char(HM)  
  debug.str(string( " Bucket Tips "))
  repeat
    tmp := rain.rainamt
    debug.CHAR(PX)
    debug.CHAR(14)
    'debug.CHAR("%")
    
    debug.dec(tmp)
  
    
Pub testpulse 

    outa [7] ~~
    dira [7] ~~
    repeat
      outa[7]~
      delay.pause1ms(1)
      outa [7] ~~
      delay.pause1ms(1000)

The obj with the cognew

Con
  fallingedge = %01110 << 26
  risingedge = %01010 << 26
  calfact = 2111
VAR
   long  tipscount, cntrpin, testval, cntrpinmask,cog,rainstack[10]
OBJ
delay : "timing" 

Pub Start (datapin)
    Stop 
    cog := cognew(getrain (datapin),@rainstack)+1
    outa[18]~~
    dira[18]~~
    delay.pause1ms(500)
    outa{18}~
    result := cog
   
Pub getrain(datapin)|cntrpin_
   outa [16] ~~
   dira [16.17] ~~
   delay.pause1ms(1000)                              ' wait one second
   outa [16] ~
   

   cntrpin_ := datapin
   cntrpinmask := |< cntrpin_
   dira[cntrpinmask] ~ 
   ctra:= fallingedge  + cntrpin 
   frqa := calfact
   phsa  := 0
   

PUB Stop
if cog > -1
  cogstop(cog -1) 'Stop previously launched cog   

Pub rainamt : amount
   outa[17]~~
   delay.pause1ms(250)
   outa[17]~
   amount := phsa
   return amount   
      
Pub resetrainamt
    phsa := 0

Jim

kuroneko · 2013-02-16 06:35

What do you expect to happen? getrain will eventually exit and therefore shut down the counter. Calling rainamt - OTOH - will return phsa for the calling cog.

Mike Green · 2013-02-16 06:41

Your stack in the OBJ is marginal in size. I'd make it 20 elements. Another problem might be the use of delay from more than one cog at a time. Why not just use "waitcnt(clkfreq/2+cnt" instead of "delay.pause1ms(500)" and "waitcnt(clkfreq+cnt)" instead of "delay.pause1ms(1000)"?

MagIO2 · 2013-02-16 10:12

@Mike:
Do you know the timing-object? In general there should be no problem in using the same object in different COGs at exactly the same time! That's one benefit of objects and each object causing trouble in this usecase either needs to have a good reason and proper ducumentation of this exception or I would call it a bad object-design!

@RS_Jim:
kuroneko already explained what is wrong with this object (it immediately stops running which also stops the counter), but there is another bug which might survive for years until it causes trouble! You don't reset the cog-variable in the stop-function and you check for the wrong range!

Pub Start (datapin)
    Stop 
    cog := cognew(getrain (datapin),@rainstack)+1
    ...

cognew returns values from 0-7 if a COG has been started and -1 if no COG has been started. Because of the + 1 the value in cog has a range from 0 to 8 (0=no COG started, 1-8=COGID)
Now compare this with your stop-function:

PUB Stop
  if cog > -1
    cogstop(cog -1)

It should be "if cog>0" or even shorter "if cog"
And you should set the variable cog to 0 after doing the cogstop! Otherwise calling stop might stop other COGs which is not intended!

Actually your code tries to stop COG 7, as the variable cog is initialized with 0 when starting up the propeller. 0 > -1 is true and 0 - 1 = -1 = %11111111_11111111_11111111_11111111 which is used by cogstop just like a 7 = %111.

RS_Jim · 2013-02-16 11:53

I put the LEDs into the object to trace where it was going. LEDs 16and 17 never light. I did have getrain at the end but it
Never got from start to certain so I moved it to just after start to see if that would work. The object does work, just not with the cognew.
Jim

kuroneko · 2013-02-16 15:52

RS_Jim wrote: »

The object does work, just not with the cognew.

Each cog has its own counter pair. Simply calling the methods from cog N will setup counter A_N and return reads for phsa_N, OK. Putting the counter setup into a new cog will setup counter A_M and still only read from phsa_N, NG. Why would you delegate a counter setup into a different cog anyway? Provided you don't use all caller's counters already you might as well stick with calling those methods.

RS_Jim · 2013-02-16 16:47

My goal was to set up counters in more than one cog and access the results from the central caller. Ok, why when I start the counter In Am do i get phsa in An?
Part of the goal here is to learn how to get multiple cogs running and get predictable results from each. Some of the cogs will be pasm and I am confident a can read the results and report them back from there, but this simple task did not seem to merit asm.
Jim

kuroneko · 2013-02-16 17:02

RS_Jim wrote: »

Ok, why when I start the counter In Am do i get phsa in An?

phsx is a cog register only available in said cog. Other cogs can't access it unless cog M shares it through hub. In your example the primary cog calls method rainamt which accesses phsa. This phsa is the primary cog's phsa (because the method runs in the context of the primary cog) and since this counter isn't used you'll most likely read 0.

If you want to share counter data from different cogs have them run some loop which occasionally samples and (optionally) resets phsx then stores it in a central hub location.

cognew is NOT!

Comments