<simpletools.h> long count ( int pin, long duration) doubles expected result?

Comments

• DavidZemon Posts: 2,973

  2014-10-24 12:09 edited 2014-10-24 12:09

  The documentation isn't too clear on this, and I could be reading the source code wrong, but it looks like the second parameter of `count()` is pretty odd.
  
  Source

  19 long count(int pin, long duration)            // count function definition
     20 {
     21   /*
     22   if(!st_pauseTicks)                             // If global dt not initialized
     23   {
     24     //set_io_dt(CLKFREQ/1000000);             // Initialize dt
     25     if(st_pauseTicks == 0) set_pause_dt(CLKFREQ/1000);
     26     set_io_timeout(CLKFREQ/4);                // Initialize timeout
     27   }
     28   */
     29   int state = 1;                              // Initialize state to 1
     30   long transitions;                           // Declare transitions var
     31   int ctr = (10 << 26) + pin;                 // Positive edge ctr config
     32   long tf = duration * st_pauseTicks;            // Set timeout
     33   int t = CNT;                                // Mark current time
     34   // Wait until pin matches state or timeout.
     35   while((input(pin) == state) && (CNT - t < tf));
     36   if(CTRA == 0)                               // If counter A unused
     37   {
     38     CTRA = ctr;                               // Start counter module
     39     FRQA = 1;                                 // Increment PHSA by 1 per edge
     40     t = CNT;                                  // Reset current time
     41     PHSA = 0;                                 // Clear phase accumulator
     42     while(CNT - t < tf);                      // Wait for timeout
     43     CTRA = 0;                                 // Stop the counter
     44     transitions = PHSA;                       // Record pos edge crossings
     45   }
     46   else if(CTRB == 0)                          // If CTRA in use, use CTRB
     47   {
     48     CTRB = ctr;                               // Equivalent to CTRA block
     49     FRQB = 1;
     50     t = CNT;
     51     PHSB = 0;
     52     while(CNT - t < tf);
     53     CTRB = 0;
     54     transitions = PHSB;
     55   }
     56   else                                        // If both counters in use
     57   {
     58     transitions = -1;                         // Return -1.
     59   }
     60   return transitions;                         // Return transitions
     61 }
  

  
  Take a look at line 32. Documentation on `st_pauseTicks` says it defaults to 1/4 second, which would imply that if you call `count(0, 1)`, you should expect to get a return value of 250 for a 1000 baud signal.
  
  0.25 * 1000 = 250 seconds. That will overflow the `tf`.
• ganzuul Posts: 8

  2014-10-24 12:30 edited 2014-10-24 12:30

  That... is... strange. I counted a duration of 10 000 to about 10 seconds, so I presumed...
  
  Are you sure you're not thinking of st_timeout?
  st_timeout = 250*st_msTicks; in http://david.zemon.name/PropWare/timeTicks_8c_source.html (Thanks for the link!)
  
  And did I miss something in calculating tf in my head? I don't feel a long should overflow at these values...
• kuroneko Posts: 3,623

  2014-10-24 12:34 edited 2014-10-24 12:34

  Works for me. Clock source being an on-chip counter (NCO, frqx = 53687 @80MHz). count(pin, duration) returns duration in this case.
• ganzuul Posts: 8

  2014-10-24 15:25 edited 2014-10-24 15:25

  Kuroneko could you reiterate on what you just said? I think you packed your data too densely for me.
• kuroneko Posts: 3,623

  2014-10-24 23:44 edited 2014-10-24 23:44

  ganzuul wrote: »

  Kuroneko could you reiterate on what you just said? I think you packed your data too densely for me.

  Sure, as I don't have external h/w for generating a pulse wave I programmed a cog counter (NCO mode) to generate a 1kHz square wave (frqx = 53687). The latter value is derived from the following equation: f = clkfreq*frqx/2³² (see counter application note). This counter runs in the same cog as the count function which means I had to modify said function slightly to not use its braindead input(pin) call. The pin is tested directly with the pin mask (see below). With all that I get the expected number of low/high transitions. IOW a call to count(16, 1000) returns 1000, cutting the frqx value in half (lower frequency) will also half the returned value.

  /*
    PulseMonitor.c
  */
  
  #include "simpletools.h"                      
   
  long count_local(int pin, long duration) {      // count function definition
      [COLOR="#FF8C00"]int state = 1 << pin[/COLOR];                       // Initialize state to pin pattern
      long transitions = -1;                      // Declare transitions var with default response
      int ctr = (10 << 26) + pin;                 // Positive edge ctr config
      long tf = duration * st_pauseTicks;         // Set timeout
      int t = CNT;                                // Mark current time
  
      while (([COLOR="#FF8C00"]INA & state[/COLOR]) && (CNT - t < tf));    // Wait until pin matches state or timeout.
  
      if (!CTRA) {                                // If counter A unused
          CTRA = ctr;                             // Start counter module
          FRQA = 1;                               // Increment PHSA by 1 per edge
          t = CNT;                                // Reset current time
          PHSA = 0;                               // Clear phase accumulator
          while (CNT - t < tf);                   // Wait for timeout
          CTRA = 0;                               // Stop the counter
          transitions = PHSA;                     // Record pos edge crossings
      } else if (!CTRB) {                         // If CTRA in use, use CTRB
          CTRB = ctr;                             // Equivalent to CTRA block
          FRQB = 1;
          t = CNT;
          PHSB = 0;
          while (CNT - t < tf);
          CTRB = 0;
          transitions = PHSB;
      }
      return transitions;                         // Return transitions
  }
  
  int main(int argc, char **argv) {
      long clocks = 0;
  
      DIRA = 1 << 16;                             // pin 16 output
      CTRB = (4 << 26) | 16;                      // NCO on pin 16
      FRQB = 53687;                               // 1kHz
       
      waitcnt(CLKFREQ*3 + CNT);
      clocks = count_local(16, 1000);             // count for 1000 ms
      print("%d\n", clocks);
      
      exit(0);
  }
  

  That being said, are you sure your generated pulse wave has the right frequency?
• ganzuul Posts: 8

  2014-10-25 06:45 edited 2014-10-25 06:45

  I'm not certain of it, no. I'm actually getting completely different results now. The 1000kHz pulse returns ~86 000, and the signal I'm interested in measuring clocks in at ~1MHz higher than before; about 14.5MHz. Variance is still in the same order of magnitude which makes me really wonder about clock recovery.
  
  Perhaps it is time I scratch together the money for a real scope. I have been investigating a very cheap USB one called the DDS120, and the signal I'm trying to get from it is its Encode clock sent to the ADC. The device is cheap enough that one might leave it in a permanent installation, or upgrade from an RTL-SDR, but it needs new firmware. Three others have started to work on the same project and by now I'm barely keeping up with them.
  
  Thank you very much for your help! I'll study the code you posted in detail. =D
• DavidZemon Posts: 2,973

  2014-10-25 16:12 edited 2014-10-25 16:12

  ganzuul wrote: »

  I'm not certain of it, no. I'm actually getting completely different results now. The 1000kHz pulse returns ~86 000, and the signal I'm interested in measuring clocks in at ~1MHz higher than before; about 14.5MHz. Variance is still in the same order of magnitude which makes me really wonder about clock recovery.
  
  Perhaps it is time I scratch together the money for a real scope. I have been investigating a very cheap USB one called the DDS120, and the signal I'm trying to get from it is its Encode clock sent to the ADC. The device is cheap enough that one might leave it in a permanent installation, or upgrade from an RTL-SDR, but it needs new firmware. Three others have started to work on the same project and by now I'm barely keeping up with them.
  
  Thank you very much for your help! I'll study the code you posted in detail. =D

  
  We've had oscilloscope threads here before. There's lots of praise for both Propalyzer and Saleae's Logic line.