I Thought I was beginning to understand counters

RS_Jim · 2013-02-14 08:10

So my task is very simple. Each time the bucket tips I want phsa to increment by the calabration number determined for the raingage.
I have set up the counter with the neg edge detector no feedback. The following is my test code

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 = %0100_0000
OBJ

  debug : "Parallax Serial Terminal"
  rain  : "raingage021413a"
  delay : "timing"
  
Pub Main | tmp            
  debug.start(115200)
  debug.str(string( " Bucket Tips "))
  rain.Start(7)
   repeat
    tmp := rain.rainamt
    debug.CHAR(PX)
    debug.CHAR(14)
   
    
    debug.dec(tmp)
'raingage obj
Con
  fallingedge = %01110000_00000000_00000000_00000000
  risingedge = %01010
  calfact = 2111
VAR
   long  tipscount, cntrpin, testval
OBJ
  delay : "timing"

Pub Start (datapin)
   cntrpin := |< datapin
   tipscount :=0
   
   ctra:= fallingedge  + cntrpin
   frqa := 1' calfact
   phsa  := 0
   OUTA[CNTRPIN] ~
   outa [16] ~~
   dira [16] ~~
   delay.pause1ms(1000)                              ' wait one second
   outa [16] ~
   outa[cntrpin] ~
   

Pub rainamt
 
{   repeat
        waitpne (cntrpin,cntrpin,0)
        waitpeq (cntrpin,cntrpin,0)
        tipscount := tipscount +1
        Return(tipscount)
 }
    repeat
      tipscount := phsa
      'Return (testval) 
      Return (tipscount)
    
      
      
Pub resetrainamt
    phsa := 0

The tipping bucket works with test code that uses waitpne/waitpeq and the Parallax usb scope shows a clean negitive going pulse. So when I run the above code, the counter seems to keep incrementing without the bucket moving. So where am I misunderstanding the counters?
Jim

Mike Green · 2013-02-14 08:17

One obvious thing ... do "ctra := fallingedge + datapin" instead of "ctra := fallingedge + cntrpin"

Remember that cntrpin is a bitmask and ctra needs a pin number.

Bean · 2013-02-14 08:19

The hardware counter is able to detect much faster edges than the waitpne/waitpeq loop (spin is not all that fast). So there is probably very fast bounce in the signal that is getting counted.

Bean

RS_Jim · 2013-02-14 08:25

Thanks Mike, so I replaced cntrpin with datapin and it still increments!
Jim

RS_Jim · 2013-02-14 08:29

Thanks bean, I don't see any bounce on the scope. However the counter keeps going with the bucket disconnected from the input port.

Ariba · 2013-02-14 08:41

Your have the counter mode bits at the wrong position if you write:
fallingedge = %01110000_00000000_00000000_00000000

The counter mode is in the bits 26..30 and not 27..31, it's much better readable if you write:

fallingedge = %01110 << 26

Andy

Tracy Allen · 2013-02-14 08:44

Jim, you have the high byte of fallingedge as 01110000 when it should be 00111000. The way you have it is "LOGIC B" mode, not NEGEDGE.

PS: what Andy said!

RS_Jim · 2013-02-14 08:45

I have tried shorting the input pin to both ground and + 3.3

RS_Jim · 2013-02-14 08:51

Ok, so I tried Andy and Tracy suggestion and bucket tips stops incrementing at all.

RS_Jim · 2013-02-14 08:58

The bucket sensor is a hall effect sensor that generates a very nice clean negative going pulse.
Jim

Ariba · 2013-02-14 09:31

You use at several positions in the code a pin mask instead of a pin number (OUTA[], DIRA[] CTRA (as Mike said)

Here is a modified version of the raingage code:

'raingage obj

Con
  fallingedge = %01110
  risingedge = %01010
  calfact = 2111

VAR
   long  tipscount, cntrpin, testval

Pub Start (datapin)
   cntrpin := datapin
   
   ctra:= fallingedge<<26 + cntrpin
   frqa := 1' calfact
   phsa  := 0
   outa [16] ~~
   dira [16] ~~
   waitcnt(clkfreq + cnt)   
   outa [16] ~
   
Pub rainamt
   return phsa

Pub resetrainamt
   phsa := 0

Andy

RS_Jim · 2013-02-14 09:51

So now I am more confused than ever,
I created a test obj which I started in a new cog:

Pub testpulse 

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

and the counter behaves correctly

RS_Jim · 2013-02-14 10:04

Thanks for the input Andy. I tried your changes but still no joy from the bucket. When I start the testpulse cog, the counter increments about 1 per second as I was expecting. So it appears to be a hardware interface issue. But why would it work using the code with waitpeq/waitpne and not with the counter?
Jim

tonyp12 · 2013-02-14 10:26

>waitpeq/waitpne and not with the counter?

How far away is this hall effect sensor?
Probably a open drain type output?, though its falling edge output should be pretty fast.

Counter need faster fall and rise times than waitpeq (I would assume)
Maybe you you need to insert a Schmitt buffer closer to the Prop.

RS_Jim · 2013-02-14 11:27

Ok, it always helps to connect the hall sensor to the pin that the counter is looking at! I had disconnected sensor from seven and put it back on six. Now with the mods all is working well. Now to see if I can get rain gage to run in its own cog.
Thanks for all the help guys!
Jim

Bean · 2013-02-14 11:34

LOL, I think we've all been there Jim.
I spend hours on a PropBasic program to read from an SD card, only to discover that pin P0 was bad on my demo board (I must have shorted it at some time).

Bean

jmg · 2013-02-14 11:35

RS_Jim wrote: »

So now I am more confused than ever,
I created a test obj which I started in a new cog:
..
and the counter behaves correctly

Self test code is always a very good idea, as it proves the logic, without the extra variables.

Another self-test is to generate the test edges on a separate pin, and couple that to the Test pin, via a RC. That gets closer to a real edge, and you can test the tolerance & failure modes, to edge slew

Edit: To get some ballpark numbers, take a sample rate of 12.5ns and choose a nominal signal noise level of 10mV (prop pins have no hysteresis), then rise/fall times need to be faster than ~ 3.7us.
(the faster that is, the move mV between samples, and the better the noise immunity)
Most logic will meed that, but some Opto-devices could struggle.

I Thought I was beginning to understand counters

Comments